Networking problem with Seventeen or Bust

[Dr.No]

Ok I know that Seventeen or Bust is not one of the DC projects
supported by Free-dc but I was looking for something new and
wanted to give it a try.

I got the client ok and retrived a work unit block to crunch on.

The problem came when I went to connect to the server to
report the completed WU and get another.

The client says that it is signing into the server but does not
report the completed WU.

I emailed one of the people at the web site on Monday
about my problem but no responce as yet.

Ok the question is about the posibility of needing a proxy-server
in order to make this work.

The reason I mention proxy is because I am on Time Warner Cable in Houston and have had to use their proxy with the
Distributed Folding client.

But the SOB client dosn't have a configuration place for me to
put the proxy info.

Any ideas?

Dr.No

[FoBoT]

there is a place to put in a port number in the same screen as where you give it your user name, did you try chaning that?

i am not sure the client supports proxies at all, i have only run it at home through my cable modem

you did change the user name from anonymous to whatever your's is?

[Dr.No]

Originally posted by FoBoT
there is a place to put in a port number in the same screen as where you give it your user name, did you try chaning that?

i am not sure the client supports proxies at all, i have only run it at home through my cable modem

you did change the user name from anonymous to whatever your's is?

What would I change the port number to?
Yes I changed the user name to my user id

[FoBoT]

i dunno, i guess you could try 80, it might hit your proxy that way, but then it may not connect to the 17 server

there isn't any info on the site regarding proxy support, my guess is that proxies aren't supported, sorry i don't know :(

[ColinT]

I am actively running SOB on Road Runner, San Diego. There is no proxy involved.

This is the SOB discussion page at Ars:

Seventeen or Bust (http://arstechnica.infopop.net/OpenTopic/page?a=tpc&s=50009562&f=122097561&m=7430977434&r=1370902634#1370902634)

It says there is no HTTP Proxy so far. Looks like nothing has been done since it was released.

Catch me if you can! http://sob.pns.net/stats/userstats.shtml?username=ColinT

Colin

[jjjjL]

Hey guys, this is Louis Helm, one of the founders of SB.

Colin invited me to the forum to read your comments... so here I am!

Dr.NO - Since you have sucessfully downloaded blocks, I am confident that you should not need to use proxies to upload results. Currently, due to the fact that the public version (v.9) has no caching support, the server expires blocks out after 5 hours and denies them after that limit. I imagine that if you check your logs, those are the kinds of messages you would see.

If you want, there is a second IP you can direct the clients toward that accepts SB traffic on other ports than 1717. Currently 216.163.34.106 is listening on ports 22 and 80. I use the first one (port 22) to do work with a computing cluster at U of M that is trapped behind a packet-filtering firewall. That's really what those ports are good for... firewall circumventing. As far as proxies go, we hear you and there may be support after v1 comes out.

Also, since I haven't made any public comments on the site recently, here's our recent dev moves:

- Had to move server from Illinois to Michigan due to our former ISPs "no server" policy.

- Currently we are integrating code from George Woltman's PRP program into SB to replace GMP as the primary math lib. Even though PRP uses far less portable code, it should actually improve compatibility and performance for those with K6s, Cyrix, and P4s.

- Trial blocks are currently non-existant because we have a single computer that can do the trial division several orders of magnitude faster than the current client does. It uses custom assembly that Dave hand optimized because he's just a badass like that. ;) Plans may change but the hope is that no more trial division will be done by the clients which will make SB use less mem and disk space. yea!

- Dave has completely rewritten the network code interface we are using. It will break compatibility with v.9 but we will just make a new IP for the next server to listen on so people will have time to migrate. I say this now not knowing for sure that this will be easy/sane. In reality, the old server phase out may not be so graceful. We'll probably just leave numbers less than a certain limit on the old server and when they run out, the old client will no longer connect.

- I want to make teams. They will exist but not until after the next (substantially faster :cool: ) version is released.


Colin mentioned the idea of a larger Top Producers page with 100 people. I have been thinking of similar things and I see no reason why we couldn't make that. Again, this will come after v1 is finished.

As a final note, I'd just like to point out that the support for our project in this early stage does not go unnoticed. Together we have managed to raise the upperbound of the current k value by over 100% since we started! But do believe me when I say this: We're just getting started :D


--
Louis Helm
lhelm@umich.edu

[FoBoT]

Originally posted by jjjjL

- I want to make teams. They will exist but not until after the next (substantially faster :cool: ) version is released.

We're just getting started :D


--
Louis Helm
lhelm@umich.edu

sounds good, teams are essential ;)

and adding cacheing will be a big help

looking forward to v1.0! :)

[ColinT]

Thanks for expanding on the new prospects Louis! Faster clients are always a good thing:)

[FoBoT]

while we are at it here, anybody know how the Pentium 4's compare on this project?

do they fair well compared to P3's/AMD's or are they poor like some other math projects?

[ColinT]

My 2000 Northwood is not as good as my XP1800s

[jjjjL]

FoBoT - P4s have miserable performance with the current version. At one point I compiled a SSE2 enhanced client that gave the P4 90% of the perforance of an Athlon at similar speeds but, alas, a bug in GMPs memory handling in the SSE2 optimizations causes it to trash the networking interface in SB so that it could not return blocks it completed. :(

Athlons have superior performance to P3s by a large margin. There are many reasons for this, most having to do with the superior memory bus.

Given processors of the same speed, they would be something like:

Athlons > P3 > Celeron > P2 > P4

It seems really perverse that P4s would be so slow on a per clock basis but in reality, it is still ok. I don't have exact numbers but a couple friends of mine get around 1000cEM/s w/ 2GHZ P4s which isn't bad but at that speed you'd expect better. Oddly enough, Athlons tend to get approximately 1cEM/s per MHz! A housemate of mine with a 1.4GHZ gets 1400cEM/s. Considering how arbitrary a unit cEMs are, it's amazing that they would correlate with something so concrete. Go figure. :)

Please note however that the relative performance of processors is going to change when GMP is replaced by PRP in v1. I expect to see P4s to go from being one of the slowest processors to being the fastest. Athlons will still be fast, just not by the 50% margin or so they currently enjoy over P3/P4s.

Another interesting thing I have discovered is that overclocking (higher FSBs) tends to help enormously. I did a very modest overclock of my 1GHz athlon to 1050MHz by uping the FSB from 133 -> 140MHz and it made my processing speed jump from ~1050cEM up to >1200cEM!

These results make me believe that v.9 is completely memory bandwidth limited. v1 should be less memory dependent. Woltman estimates PRP to be around 10% memory limited as opposed to my estimation of SBs current 100% limitation ;) I recently took computer organization at U of M and the main theme I came away with is that cache is *good*, memory is baaaaaddddddd. Woltman is able to squeeze almost the entire calculation in cache. GMP has so much overhead and is so general that it doesn't even come close.

Long story short: Athlon > P4. PRP > GMP.


--
Louis Helm
lhelm@umich.edu

[FoBoT]

thank you, this seems to be the case with P4's and almost all DC projects :rolleyes:

good thing they belong to the company, i have AMD's at home :D

[ColinT]

I checked my three remaining boxes:

P4 2000 = 834 cMEs/sec
XP1700 = 1841 cMEs/sec (1468 MHz)
1400 Tbird = 1665 cMEs/sec


That is a big clue about the worthlessness of P4s

[Nitrousine]

That's why I'm going to take my P4 and put it back on DF.

P4 1.4Ghz = 570 cEMs/sec
Duron 900@1025 = 1240 cEMs/sec

:rolleyes: