rc5 client causing a >50% drop in rendering performance

[dennilfloss]

From what I kept reading, I was under the impression that the client did not affect any process. That is why I include the following statement in my recruiting invitation.

"The program (client) is set to the lowest priority on your computer, meaning that it will not slow any of your processes."

However, one of my candidates tried the client for a while and came back to me with this sobering message:

--------------------------------

It does slow the single most important process on my network, rendering. I tested time and time again and it kills performance, dropping it nearly 50% on average, sometimes more.

I'm running render software based on the LightWorks engine, use it over my LAN, and every single machine suffers a major performance hit with the client(PII, K6-2, Athlon). I have avoided posting this on the forums as to not hurt recruiting efforts as I was running and actively recruiting for a while, and with the exception of that particular render engine I have had no problems.

The big issue is, the performance of that engine is why I have a LAN and why I spend as much money as I do on my machines. Nothing else was effected at all, didn't lose a tenth of a FPS in any game nor were any other functions slwed in the least. I know how the program is written and the only thing I can think of is the fact that it resides in L1 cache creates a situation in which the data set is not available for the render and needs to hit L2(1/2 speed K75 Athlon) slowing things down considerably.

-------------------------

Have I inadvertently misled people and is there a way to go around this performance drop in rendering? Are there other similar issues of which I am unaware? Otherwise I will include a carefully worded warning into my invitation. To do otherwise would be unethical in my book.

If anyone can shed some light on this phenomenon, I would really appreciate it. I don't like to make inaccurate statements.

 

[Michael]

Not sure if it was the same person, but I was told that the RC5 client does slow down rendering programs. Since it only seems to hurt high-end rendering programs, I wouldn't worry about it.

There are a couple of choices, the best of which is to run SETI or RC5 as a screensaver which should only come on when the computer is not being used. Or turn off the client when rendering.

Michael

 

[mechBgon]

Hmm, wonder what causes that. I do some rendering using trueSpace 4.3 and the client has no effect on the speed, but then again tS 4.3 doesn't do distributed rendering either. Maybe there's some latency in the "other" computers' switching from RC5 to the rendering process, but it seems to me that the computer would only have to do that at the beginning of the render, not over and over.

 

[ViRGE]

Unfortunately, this is one of those occasions where we're wrong. There are a handful of programs that don't load-share properly with the Dnet client, and it looks like this is the case. You didn't do anything wrong Dennil, this is just one of those bad luck things.

 

[Ken g6]

RC5 should only interfere with a process running at the lowest possible priority. This could be the case if this is some kind of distributed renderer. You can check the priority of your rendering program with Another Task Manager if your don't have WinNT/2K's Task Manager. There is also a free program you could use to up the rendering process' priority automatically, but if the thread is set to minimum priority, you'd have to use the above program manually.

Generally, RC5 only interferes with other distributed computing or idle (e.g. Rain) applications, and even then not often. There is also an option to stop the client when a given executable is running, if it would help.

To be perfectly correct, this quote would be accurate: "The program (client) is set to the lowest priority on your computer, meaning that it will not slow any of your normal processes (or even most idle processes)."

 

[JonB]

I have very recently tested this while rendering in Adobe Premiere 5.1c. Because it will use SMP, I was particularly interested. I did not notice any impact on rendering times. In fact, with RC5 off, Premiere was only using 30% of each CPU anyway.

Just ran a short rendering session in Ulead Video Studio 3.0. While it doesn't support SMP like Premiere does, it only cost me $5.00 versus $200. Anyway, RC5 on or off made no noticeable difference.


I agree that this particular software spawns a few threads that also have the "lowest" priority and therefore can't get all the CPU time they need.

 

[dennilfloss]

Thanks people. I have altered my invitation accordingly.

 

[Kilowatt]

Have him add the rendering_programs.exe to the clients Halt_on .exe list.

That'll stop the client when he is using the rendering program, like it does when you use windows defrag.

 

[Fandu]

I would be really interested in getting to the bottom of this also. I've done a bit of work with the dnet clients, and from a theoretical standpoint, they should give up all CPU time called for by any other process. There is no reason that is should interfear with other distributed computing programs as the client runs as a single, local process, not a LAN wide process. Try using a program like WinTop to have a look and see what the priority of LightWorks and it's associated threads are. Or, alternativly, try having him run another program like Prime95 in the background and see if it has the same effect. If it does, then it certinally sounds like the priority of the render is set way too low.

 

[xtreme2k]

i think what happens is that the
rendering thread is ALSO on IDLE priority
therefore it shares the time 50/50 with the RC5
therefore the 50% speed degration

that is the only valid explaination i know

 

[DegenerationX]

I'm not sure if this is a related issue or not, but I've run into two similar situations where I have had to manually shut down the client.

1) Running defrag on Windows Millennium - I can see it halt the process but for some reason the defrag continues to reset itself stating that the disk was changed.

2) Running the client on a Novell 5.1 server with Netscape Enterprise Webserver and Novell's FTP server pretty much kills the server. (haven't been able to investigate this much since it's a production box)

I'm just wondering if anyone else has seen these problems.

 

[Fandu]

DegenerationX: The first problem your describing is simple. When the client is running, it saves it's work ever minute or so, so that if the computer freezes, gets powered off, whatnot, it doesn't lose the current packet it's on. So when you have Defreg and the client running, the client keeps writing data to the disk every few min, and defrag will continue re-starting.

So for the Novel problem, you would need to check the priority on all the threads.

 

[ViRGE]

The client should auto-pause for defrag. It may however be that Dnet has never tested that feature on WinME.

 

[IsOs]

Rc5 does show some slowdown for AutoCAD as well. Not sure how much exactly, but enough for the user to complain and the boss said loose it.

 

[Eug]

Yes, it is misleading to say that it does not affect performance. I have noticed the slowdowns myself - irritating with 3D programs (ie. games/benchmarks).

 

[The Stigenator]

I have noticed it too. Infact I have taken it off several critical 3d rendering systems. Its running on teh servers only now.

 

[LeBlatt]

I do have an issue with GDI or WPS printers like Canon LBP-660, which have no onboard CPU and use the host CPU to raster pages. Users get either blank or all-black page with the message "reduce computer activity when printing".
Since there is no particular EXE launched when printing, I have to cut dnet on them.

 

[DegenerationX]

Windows Millennium, DNet & Defrag ... works fine on my machine at home, but 2 of my machines at work don't. Of course it's a simple step to add a 'dnetc -shutdown' command to the beginning of the process and a 'dnetc -svcstart' to the end, but it is strange. These machines are also on a Novell network using the Novell network client (v3.30), so maybe it's something related to Novell that just doesn't like the client. So far the only thing I've checked on the server was that it didn't have the switch on to upgrade low priority processes since that's what it appeared to be doing. Soon I'll have a Novell test environment to play with so I'll do some more investigating then. Now to see about setting up those two quad processor Sun's ...

---

DegenerationX,

Your emailed subscription updates are being returned to us with the error message,

Recipient: <DegenerationX@ecompare.com>
Reason: <DegenerationX@ecompare.com>... Relaying Denied. Check your mail using POP3 first to enable SMTP.

Please remember that we require our members to have a valid email address in their profile. Please update your profile to correct this problem, and please do not subscribe to any more threads until your email is working correctly. These returns clog our mailbox, so I have cancelled your current subscriptions.

Thank you,

AnandTech Moderator

 

[dennilfloss]

The rc5 client has no effect on my Ontrack Utilities 2000 Defrag (which is much faster than Windows') in Windows 98.