nfsnet down

[fivemack]

at least, I can't ping initial.server.nfsnet.org and so have been unable to collect the polynomial and bounds for 2^772+1.

Can't get through to bristol.server.nfsnet.org either.

[Wacky]

Originally Posted by fivemack

at least, I can't ping initial.server.nfsnet.org and so have been unable to collect the polynomial and bounds for 2^772+1.

Can't get through to bristol.server.nfsnet.org either.

The NFSNet servers respond only to their own protocol.
All of them are behind some sort of firewall which limits the ports which are visible.

If you are familiar with the CWI line siever parameters,
this is what we are using for this project.

# in file start
ID Unknown
POOL pond
PROJECT 2_772P
SUBPROJECT 2_772P_2
LP 1 1
B bmin bmax
A 0 108000000 1
CA 0 0.80 2.00 0 0.80 2.00 18000000
PB 1 0 0 1
SI 50 20000 0 0
MS 0 10000000
P 50000000 1000000000 E 2 200
P 50000000 1000000000 E 2 200
# in file end
# polys file start
33618214346301495207886654953490196570126204843865570895449052714337501820593606749126247032282361181579401446139400175244149029971292377891951540380505097100625301465806913382807017720867990060875740325222109174241

680564733841876926926749214863536422912

2
1
-680564733841876926926749214863536422912 1
6
4 0 0 0 0 0 1
50000000
# polys file end

[fivemack]

This clearly isn't an infrastructure problem, it must be some sort of client issue, because I ran the nfsnetclient registration while sniffing all packets coming in and out, and didn't see it emitting any packets.

The nfsnetclient version I downloaded from the Web page is compiled against libstdc++.so.5 and the Ubuntu-7.04 system I'm running on uses libstdc++.so.6. Failure to interact properly with DNS, which would explain what I've been seeing, is a known side-effect of running binaries statically linked against libstdc++5 on a libstdc++6 system.

And, indeed, if I change 'initial.server.nfsnet.org' to '216.177.163.56' in my processors/config.txt file, the registration is successful, though everything that I get from the servers refers to hosts by textual addresses so I run into the DNS problems again.

I'm not sure there's any solution possible except producing a version of the nfsnet tools compiled against libstdc++.so.6; I don't know how hard that would be.

[Wacky]

Originally Posted by fivemack

I'm not sure there's any solution possible except producing a version of the nfsnet tools compiled against libstdc++.so.6; I don't know how hard that would be.

It should be rather easy to recompile the "nfsnetclient" which does all of the communications. The siever itself is another matter. However, since the siever does not do DNS, perhaps the current one will work.

[fivemack]

Originally Posted by Wacky

It should be rather easy to recompile the "nfsnetclient" which does all of the communications. The siever itself is another matter. However, since the siever does not do DNS, perhaps the current one will work.

I think only the nfsnetclient needs to be recompiled against libstdc++-6; at least, the static builds of rootfinder and linesiever from the standard distribution are running for me when I feed them input manually.

Thanks for the post of line-siever parameters, without which I'd have had to spend ages reverse-engineering nfsnetclient to figure out what input linesiever wanted to be fed!

It would be very nice, if possible, to get linesiever to understand the CPUID cache codes for things like the Core2duo I'm running it on: it's behaving as if the machine has no L2 cache, which is a little silly since there's 4MB of it. I know that the full source code for linesiever has significant restrictions on it, but would be happy to be mailed the understanding-CPUID-cache-codes part and update it for current and near-future Intel CPUs: the information is all in pages number 30-31 of http://softwarecommunity.intel.com/i...0Reference.pdf and that's got the details for CPUs up to the Penryn series which will come out at the end of 2007.

[Wacky]

We had a perfectly good piece of code. Then Intel went out and added bigger caches (with codes that we don't currently recognize). But it should not be difficult to add a few more entries to the CPUID decode routine.

[fivemack]

There's no logic to Intel's cache-descriptor codes, you just have to get newer and newer versions of the application note and constantly update the decode routine. AMD have a much more coherent set of cpuid subqueries which actually return the sizes of caches, though fit them into very narrow bit fields so they can't for example describe an offering of more than 1.75MB of level-2 cache; I suspect the syntax will change entirely for Barcelona, and the decode routine will have to be updated again. Well, it all makes work for the working man to do

Some of the cache-descriptor codes clearly don't refer to any processor that Intel ever released or is likely to release (192kb or 384kb level-2 cache? 3MB shared level-3 cache?!) but I suppose it's always good to plan for the future.

[Prime95]

Originally Posted by fivemack

AMD have a much more coherent set of cpuid subqueries which actually return the sizes of caches,.

Intel has adopted AMD's approach

[smh]

Originally Posted by fivemack

.....everything that I get from the servers refers to hosts by textual addresses so I run into the DNS problems again.

What about adding the nfsnet server to your hosts file?

[jasonp]

Originally Posted by fivemack

There's no logic to Intel's cache-descriptor codes, you just have to get newer and newer versions of the application note and constantly update the decode routine. AMD have a much more coherent set of cpuid subqueries which actually return the sizes of caches, though fit them into very narrow bit fields so they can't for example describe an offering of more than 1.75MB of level-2 cache; I suspect the syntax will change entirely for Barcelona, and the decode routine will have to be updated again.

I've just gone through the exercise of reading the CPUID output to get cache sizes, and I agree that it's a mess. However, the AMD style allocates 16 bits for the number of kilobytes of level 2 cache, so big caches are no problem. Intel has adopted AMD's style for getting level 2 cache sizes, but not for getting level 1 cache sizes; you still need to wade through all those damned feature bytes to get the size.