I have multiple various questions.

[muttley]

In Windows XP pro is there a way to see the data transfer rate of the memory? The reason I am wondering is the CPU usage at 100% taxing all of the memory? or is the on chip cache memory managing the workload. If so would PC-133 cas 2 be a cost effective solution?

Dual processors; I have read in another article processing times around 4 hours or less. Are they running one SETI program or are they running two SETI programs at the same time? If 2 then memory bandwidth isn't as important for a single processor (just cas2.) From reading on the web designed motherboards for/with DDR 333 at 2.5 cas has little meaningful improvement.

Orangekids system; I would like to learn where his bottlenecks are comming from in his system. Is his constantly trying to connect with Berkley slowing down his system? If I remember right is he using a Dual processor system. Orangekid is using 300K up/1Mb dn if he is getting slowed down by bandwidth limitations how much information is he transfering in a day and if it is so high what is the repercusions from the high speed internet service provider? I see the web page not come up at times and I wonder what the bottleneck is there. I got on Bearshare and got happy in a ~week I downloaded 4-5 or more GIGs. (I turned it off for another month ... get more selective, but 1/2 gig an episode for Startrek.) If orangekid reads this don't take it as a negative comment I am just trying to learn from real world problems. Thanks for all you do.

What information do people have on a 64 bit version of SETI for the upcomming AMD product? Isn't there a linux 64 bit OS out now and where can I find information on its expectations and limitations. Any guess what the upcomming AMD cpu price will be? Microsoft ugh what will they charge 64-bit 32-bit compatibility?

Anybody know about roadrunner home and business accounts. How much is to much download/upload usage and is a business account allowed more 'Bandwidth transfer in MEGABYTES' and when they say 4,500 Megabytes what period is that for? month?

I was reading in the forum about moving around to different proxys was a no-no what about turning off the proxy and downloading wu from SETI and then reconnecting to proxy to save and send the work units up to the proxy? Like I'm up right now in the am hours and when it says 'will try in another hour' I close the box for another try instead of the computer waiting an hour. Is there a way to make the time less than an hour? What is the purpose of putting the check mark in front of the Use SETI Driver? Arn't we already using the SETI Driver??? If I'm up in the am hours of SETI and can download wu can I zip them and send them to one of the proxy people by email? would that help?

Now for question #2 part A of 243 subparts

muttley

 

[Confused]

I'm not sure as to the Windows XP memory question, but for dual processors, it is running 2 copies of the client, one "attached" to each CPU. The sub 4hr times are for the Athlon XPs, and they are slightly slower than just a single processor machine of the same clock speed as each of the processors, as on the dualie, both processors share the same memory bandwidth. Memory bandwidth is important for both a single and dual processor computer when running Seti, because, like say a cable modem, you can get different speeds, from (for example in the UK where i am) 64kbps down, to 512kbps down. The both have the same latency, i get the same pings in CS or Quake 3 with both, but with the higher bandwidth one, it takes less time to transfer the same amount of data.

Not sure about the stuff with OK, will have to wait for him to see it and answer himself! As for 64bit client for new AMD processor, not a clue, will have to talk to Berkeley about that.

As for Roadrunner, don't know, am in the UK. I know that sometimes a bandwidth limit is not good, because you would normally get charged if you went over that limit, and it is normally per month.

When you move around all the proxies, they create a queue for you, and try to download WUs, or the Queue Master manually moves WUs into that queue so that all the queues have a supply of WUs. If the person does not come back to that queue, then it is possible that it is deleted, and any WUs that were moved there could be lost forever. This is a bad thing because we are very low on WUs, and can't afford to lose any. The only way to get it to connect and try more often that every hour is to connect it to a queue, which will try itself every few minutes (depending on how it is set up) or to close the box and set it to try again yourself.

The "Use SETI Driver" box means that the progress bar will be updated automatically, without you having to press the "Update Progress Now" button, and it also shows the progress when you hover the mouse over the icon in the task bar.

If you wish to zip up some WUs in SetiDriver form, then take a look at the thread Wiz has put up with Seti WUs, and email them to him.

Hope this helps a little

ConfusedBW

 

[Poof]

:Q

muttley! That's a whole lotta questions!!!!!!

Let's see if I can tackle some:

1.) XP - you could try monitoring with Task Manager (assuming you're talking about XP Pro). There's alot of things you can configure to look at. For SETI at least, CAS2 RAM is always preferable and gives you better OC options if you're into that.

2.) Again for SETI and with duals... The problem with CPUs other than Xeons is the cache size on the CPU and how it handles a program the size of SETI. The effective CLI size is ~800K, but 3.0x allowed this to be processed in ~200K chunks at a time in order to fit in the 256K cache of a P3 or Athlon. However, this still means swapping the chunks in and out of cache, with the swaps going to your slower RAM. In dual configuration, dual P3s or AMDs will still have the program dumping to the slower RAM (although DDR is faster in comparison to say regular SDRAM), however with 2 processors involved, BOTH will be doing that in a sort of competition. Thus you get alot more task-switching and other things going on that will actually increase the WU times when compared to only running singlely. In large cache boxen (Xeon), the program CAN fit in the 1MB or higher cache and thus you'll see a ~20% improvement in processing times for the Xeon when running dual, over the same speed P3, AMD, etc. The P4 is a bizarre puppy at this point and seems to win the race out of sheer MHz, mainly because few proggies have been compiled to take advantage of the processor itself & RAMBUS.

3.) OK's "problem" is pretty much strictly the SETI problem. The SETI data server is currently limited to 1500 simultaneous connections and the bandwidth to that server is severely restricted. Thus each connection will take longer for transaction completion than before the bandwidth cap, thus it takes longer before disconnection and freeing of the socket for someone else. Also, as with any other high-speed transfer... if you try to connect while his server has made a connection with SETI and is downloading/uploading (which will happen as fast as the pipe allows, because this is how TCP/IP & ethernet operates) you will obviously run into some connection problems to his queue's web page. This would be no different than someone streaming some audio while you're trying to look at their web page.

4.) Regarding the 64-bit stuff - At this point, the porters will probably be working on slowing down the WU times and/or adding compression and/or other things with the existing clients, rather than trying to come up with a client optimized for newer processors. At the current time, it would be nice if they did compile a client for the newer AMDs, but I expect they would do it for the P4 first. Also, any linux (and *nix, like Tru64) version made for an alpha is obviously 64-bit, and have been out for quite awhile. I have Red Hat 6.2 on my alpha and use the alpha linux SETI client. I expect that maybe you're thinking about the near vapor-ware itanium , but many a *nix (and an on-again/off-again windoze) is already available to take advantage of this processor whenever it gets out there en masse...

5.) Roadrunner - Don't know about them, I have Comcast... BUT you might want to consider popping over to DSLR, which has broadband vendor-specific forums where issues like that are discussed.

6.) I think the issue about bopping around to different queues is more along the "pick one and stay with it" vein. If you let the queue hoster know that you're coming, then they can move some WUs into your new queue as soon as they can. Otherwise, they won't know to do that, the person pointing to them gets frustrated because they can't get WUs from that queue, then they leave that one and try another with the same result.

7.) Setidriver and times - the client is hard-coded to retry every hour. In order to change that, you'd have to stop and then restart to reset the 1-hour timer. Since Setidriver normally lets the client control the timing, you would need to go through the same process with Setidriver (stop/restart to reset the timer). Other queueing programs like Setiqueue, will let you configure down to trying every 10 minutes. And the checkbox for "Use Setidriver" has to do with which proggy you want to use to display your progress - and it really had to do with Setidriver having the ability to work with Setispy (which can monitor) and Setiwatch (which also monitors).

 

[muttley]

Poof

what is your times on the alpha?

And thanks both of you for the answers will reread them some more.

Best regards,
muttley

 

[Poof]

what is your times on the alpha?

I'm getting from 10 - 11 hrs/WU with my 433Mhz 21164. It's closer to the 10 hr range for VHAR and VLAR WUs and closer to 10.5 - 11 for the mids. The variability based on angle range is higher with this when compared to similar AR WUs on the x86s.

Alternately, my sparc IPX running RH 5.2 for sparc does a WU in 16 days...lol