mersenneforum.org  

Go Back   mersenneforum.org > Other Stuff > Archived Projects > NFSNET Discussion

 
 
Thread Tools
Old 2007-04-20, 23:12   #1
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

13·491 Posts
Default nfsnet down

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.
fivemack is offline  
Old 2007-04-20, 23:41   #2
Wacky
 
Wacky's Avatar
 
Jun 2003
The Texas Hill Country

44116 Posts
Default

Quote:
Originally Posted by fivemack View Post
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
Wacky is offline  
Old 2007-04-22, 09:47   #3
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

13×491 Posts
Default This is a libstdc++ versioning issue

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.
fivemack is offline  
Old 2007-04-22, 15:12   #4
Wacky
 
Wacky's Avatar
 
Jun 2003
The Texas Hill Country

32×112 Posts
Default

Quote:
Originally Posted by fivemack View Post
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.
Wacky is offline  
Old 2007-04-22, 16:18   #5
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

13×491 Posts
Default

Quote:
Originally Posted by Wacky View Post
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.
fivemack is offline  
Old 2007-04-22, 17:42   #6
Wacky
 
Wacky's Avatar
 
Jun 2003
The Texas Hill Country

32×112 Posts
Default

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.
Wacky is offline  
Old 2007-04-22, 21:00   #7
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

143578 Posts
Default

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.
fivemack is offline  
Old 2007-04-22, 21:24   #8
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×3,701 Posts
Default

Quote:
Originally Posted by fivemack View Post
AMD have a much more coherent set of cpuid subqueries which actually return the sizes of caches,.
Intel has adopted AMD's approach
Prime95 is offline  
Old 2007-04-23, 05:22   #9
smh
 
smh's Avatar
 
"Sander"
Oct 2002
52.345322,5.52471

29·41 Posts
Default

Quote:
Originally Posted by fivemack View Post
.....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?
smh is offline  
Old 2007-04-23, 14:55   #10
jasonp
Tribal Bullet
 
jasonp's Avatar
 
Oct 2004

24×13×17 Posts
Default

Quote:
Originally Posted by fivemack View Post
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.
jasonp is offline  
 

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Questions about NFSNET... WraithX NFSNET Discussion 2 2007-03-03 23:56
Overall stats for NFSNET? Mystwalker Factoring 3 2005-12-22 22:11
Questions about NFSNET koders333 NFSNET Discussion 4 2005-09-26 13:19
http://www.nfsnet.org/downloads/nfsnet-04145-powerpc-MacOSX.tgz Death NFSNET Discussion 15 2004-06-22 07:35
Welcome to NFSNET Discussion! Jeff Gilchrist NFSNET Discussion 0 2003-06-07 12:14

All times are UTC. The time now is 21:37.

Sun Apr 11 21:37:43 UTC 2021 up 3 days, 16:18, 1 user, load averages: 1.64, 2.02, 1.93

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.