Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
World Community Grid Forums
Category: Retired Forums Forum: UD Windows Agent Support [Read Only] Thread: Monitoring bandwidth usage |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 4
|
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Is there an easy way to identify and classify network traffic generated by the agent software? I'd like to set up a traffic class on my PacketShaper to monitor the bandwidth used by all clients on the network.
|
||
|
retsof
Former Community Advisor USA Joined: Jul 31, 2005 Post Count: 6824 Status: Offline Project Badges: |
Is there an easy way to identify and classify network traffic generated by the agent software? I'd like to set up a traffic class on my PacketShaper to monitor the bandwidth used by all clients on the network. This was a quote from a traffic shaper site: My "before" picture--that is, before I enabled traffic shaping--wasn't very promising. The file transfers used up more than 90 percent of all available bandwidth, pushing response time for the SAP sessions to nearly five seconds, far above the one-second limit considered optimal. Then I enabled traffic shaping. In this case, I set up a rule that restricted all file-transfer connections to 300 Kbps, with the ability to burst to a maximum of 512 Kbps if other applications didn't need the capacity. Chariot itself limited RealMedia, which runs over UDP, to an offered rate of 300 Kbps; given that my earlier baseline results suggested the PacketShaper isn't very effective at shaping UDP traffic to specific rates, I didn't attempt a UDP overload. File transfers would like to run at close to 100% if they can. They are sending everything up to secure socket 403. After it is done, the benchmark test run, and new workunit started, you can disconnect entirely. You do not have to be online at all to process a workunit. My slowest computer only has to call in every few days or so. This "traffic shaping" sounds like a way to LIMIT the file transfers and have it take even longer to complete. While you are doing that, you are not crunching. The FA@H files are especially tiny. I am only downloading a 49,000 BYTE file. There's another consideration. If you gag the traffic, you also affect the benchmark and don't get a high rating for next time. The objective is to have as little else as possible running during the transfer event.
SUPPORT ADVISOR
----------------------------------------Work+GPU i7 8700 12threads School i7 4770 8threads Default+GPU Ryzen 7 3700X 16threads Ryzen 7 3800X 16 threads Ryzen 9 3900X 24threads Home i7 3540M 4threads50% [Edit 3 times, last edit by retsof at Mar 14, 2006 9:40:39 PM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Two points:
The WCG points calculation ignores the network rating. The BOINC client does not have the delay problem, since it downloads the next work unit before the previous finishes. |
||
|
retsof
Former Community Advisor USA Joined: Jul 31, 2005 Post Count: 6824 Status: Offline Project Badges: |
The WCG points calculation ignores the network rating. That is true.Even without that, a transfer that takes longer keeps the next workunit from starting sooner. Surely, if your processor is busy, the benchmark is going to knock down your processor rating. The BOINC client does not have the delay problem, since it downloads the next work unit before the previous finishes. BOINC is a lot newer, and also runs on dual core machines. They seem to have thought of a lot. If it was NOT newer to start with, they certainly have made changes to keep up with the technology.
SUPPORT ADVISOR
----------------------------------------Work+GPU i7 8700 12threads School i7 4770 8threads Default+GPU Ryzen 7 3700X 16threads Ryzen 7 3800X 16 threads Ryzen 9 3900X 24threads Home i7 3540M 4threads50% [Edit 4 times, last edit by retsof at Mar 14, 2006 9:47:33 PM] |
||
|
|