patching performance

[aridash]

i'm getting a bit fed up with this now. every VU, once the patch is downloaded it takes about 40-50 minutes to apply, in which time my machine is rendered near useless. everything stutters and has lags and is unresponsive to action. i might write a line of text and not see it on screen for 10 seconds. i cant surf the net as pages take so long to load, cant use other apps properly either.

am i the only one suffering this and need to review my PC? or is it widespread problem and MA which needs to address to review how their patch application works?

 

[Nadie]

Mine doesn't take anywhere near that time to apply but is still pretty slow - about 15 mins today. As for performance I don't do anything at all on my PC when doing EU updates. I turn off everything I don't need including screensavers etc. then walk away and leave it until it's totally finished or something tends to go fubar with the installation

 

[jenny ferr]

50min for todays "small"(252mb)
Maybe something is up with your own machine then?

Sure it is slow and freeze almost all other but also learned to leave it to do it's job, but no where near 50min, today perhaps 5min or so (felt like 15 tho but thats just me wanting in I guess hehe)

 

[Syntaxtc]

No performance issues for me. I actually had 6 redtube videos opened and running at the time of applying the patch, and was multi-tasking between emails and my underwear.

 

[Pepto]

You should consider direct downloading the patches from the download mirror site and then installing them manually if you suffer patching through the client loader. The only issue with this method is that the patches aren't always added timeously.

 

[Micheva]

No issues for me. Im running EU on a notebook. 2.8 GHz, 4Gb RAM, normal SATA drive (no SSD). No problems here.
Servers are fast downloading (12 MB/s) and yesterdays install took about 10 minutes max.

 

[T79x]

PC run normaly and patch is unresponsive while applied

in 1/2 of VU11,+

but no problems at all no need to repair

just it take some loong time till finish

 

[Mega]

i'm getting a bit fed up with this now. every VU, once the patch is downloaded it takes about 40-50 minutes to apply, in which time my machine is rendered near useless. everything stutters and has lags and is unresponsive to action. i might write a line of text and not see it on screen for 10 seconds. i cant surf the net as pages take so long to load, cant use other apps properly either.

am i the only one suffering this and need to review my PC? or is it widespread problem and MA which needs to address to review how their patch application works?

Typically takes 5 minutes for me to apply a patch on my 2 year old pc, you may want to consider upgrading your pc (you've not stated your specification) or if it is fairly modern, perhaps defragmenting your hard disk may help ?

 

[MindStar9]

No issues for me whatsoever, and usually takes about 5 minutes or so, but quite quick.

 

[Mega]

Just had a thought that perhaps it is because I have a quad core processor, which allows the computer to get on with other tasks whilst doing the patching, is why some have no issues and others experience long waits ?

 

[Mekoides]

For me, patches apply in about 5-10 minutes and I notice no difference in computer performance before/during/after. I'm going to say it's probably a problem with your PC rather than the patching process.

-What is your OS and when did you last format/reinstall?
-How many cores does your CPU(s) have
-How much RAM do you have
-How many hard drives do you have, what speed(s), and what RAID configurations (if any)
-If you have Vista or Windows 7, what is your Windows Experience Index Rating?

I'm guessing one or more of those is causing the slowness.

For me:
-Windows 7 x64 Pro, 6 months old
-1x 3-core CPU
-8GB DDR3
-2x 7200RPM drives in a RAID1 array (double the read speed of a single hard drive)
-5.9 (due to crappy video card)

 

[bass]

Take into account that files are CRYPTED, so decrypt-patch-encrypt (I make an assumption here) is quite CPU intensive, and the more cores/MHz/RAM you have the faster you are.

Actually my patching times are a bit long, but I have a pretty dated PC.

 

[shoti]

No issues for me. Aplying patch is ca.5 mins. Using 8 years old PC here (just maintained properly).

When u last time defraged your HDD? Is your swap file set big enough?

 

[aridash]

to be very clear, the download itself is fine, as expected. its the process of applying the patch where the performance suffers.

for the record the system is a AMD X2 550 with 3GB RAM - a year old midish range machine. The HD is a Seagate barracuda 7200 which isnt too shabby either. i do regularly defrag, however one of the inherent problems with Windows is it fragments files as they download, its not possible to stop the process, defrag, apply patch.

interesting point about page file. i dont have one (whats the point with 3GB????) but that is unusual.

No performance issues for me. I actually had 6 redtube videos opened and running at the time of applying the patch, and was multi-tasking between emails and my underwear.

thats wrong... how do you keep track of 6?

 

[Lakarin]

Never had any problems with applying patches, but i use normaly nice fast rigs...

 

[Mekoides]

interesting point about page file. i dont have one (whats the point with 3GB????) but that is unusual.

Microsoft best practices require a page file sized between 150% and 200% of your physical memory size. Set your page file to be 4.5GB to 6GB.

Also - how full is your hard drive? HDD performance gets slower the fuller the drive gets. I have Seagate Barracuda 7200s myself, and I see a performance hit when they reach about 85% full.

 

[aridash]

Microsoft best practices require a page file sized between 150% and 200% of your physical memory size. Set your page file to be 4.5GB to 6GB.

to exorcise a bugbear of mine, its default practice, not best. why should it be best practice? if you understand the concept behind the page file, you'll realise there is absolutly no point to it with modern RAM availability: if you do not use all RAM (as most dont), the page file should be redundant. setting the page file to a range, and therefore variable, is one of the worst thing you can do as this lead to defragmentation of the page file and subsequent preformance problems (if it actually comes into use).

with 2GB+ RAM we should be using RAM disks, not page files.

 

[Mekoides]

with 2GB+ RAM we should be using RAM disks, not page files.

While I certainly agree that with the proper amount of RAM, a system does not need a page file, the 2GB number you gave is quite antiquated. With the mass availability of cheap memory and the rise in popularity of 64-bit operating systems, application developers have less and less motivation to make efficient use of memory.

With proper monitoring of memory consumption, it is certainly possible to have a low-memory system completely stable and optimal running without paging. Will the average Joe be able to properly maintain this? In my experience, no.

Also remember, with 32-bit versions of Windows, the virtual address space of processes and applications is limited to 2 GB unless the /3GB switch is used in the Boot.ini file.

 

[Xen]

Mine has been blazing fast since getting a SSD.

 

[sitram]

Most of the times the patch program reads those huge files from Entropia installation folder and this is why you're computer might freeze.

I watched quite often in task manager the stats of the patching task and I see that after it finishes it has like 8gb of read data and 4-6 of write data.

This might cause a heavy load on the system, especially on the HDD.

 

[jeanman]

Whit today,s patch is something wrong.My pc patching already for 2 hours.

Where i can download patch manualy?

 

[Mega]

Whit today,s patch is something wrong.My pc patching already for 2 hours.

Where i can download patch manualy?

Id be tempted to stop it and then choose tools / repair from the clientloader. Make sure you dont have a anti virus or similar program running intensively and using up your pc resources.

 

[Witte]

Patching is indeed too slow here, but I do have an ancient computer (AMD XP2500, 1GB). But my system does remain responsive during a patch. I don't even notice it.

 

[Witte]

Id be tempted to stop it and then choose tools / repair from the clientloader. Make sure you dont have a anti virus or similar program running intensively and using up your pc resources.

I was wondering how can you choose "repair" if the CL automatically starts patching when you start it? I had an error during patching some weeks ago, but could not choose repair anywhere. So I just downloaded the complete game again.

 

[Mega]

I was wondering how can you choose "repair" if the CL automatically starts patching when you start it? I had an error during patching some weeks ago, but could not choose repair anywhere. So I just downloaded the complete game again.

It's a good point, I've not had any patching problems in the past 6 months although I did have some problems in the early VU 10 days - the way the download and patching is done differs to how it used to be (ie no pop up window and integrated download window into the main clientloader window)

It is worth keeping a copy of the entire Entropia universe folder if you can spare the HD space - 5.5 gig so if a patch goes wrong you can copy it back.

 

[jeanman]

I was wondering how can you choose "repair" if the CL automatically starts patching when you start it? I had an error during patching some weeks ago, but could not choose repair anywhere. So I just downloaded the complete game again.

Ok dowload complete game sound,s good but they give you old version, and that need patching do

 

[Audrey Cheerful]

Oh, goody! I thought I was the only one with patch times over 30 minutes. Somebody at MA screwed up big time while writing the patcher.

 

[aridash]

for those that do find they suffer a similar performance hit when applying the patch, i seem to have found a work around.

assuming you have multiple cores (which is farily typical), in Task Manager under the performacne tab, go to view, CPU history and see which CPU is getting hit most when patching starts. this is the CPU which the patch is using. now, in the performance tab right click on the processes for apps you want to use while waiting, ie Firefox. from the context menu select "set affinity" and untick the processor the patch is using. now select the vpatch process and set affinity to the uncheck the one it isnt using. ie if vpatch is using core 1, set Firefoxx to use only core 0 and vpatch to use only core 1.

the first change force your app to not try and use a very busy processor, Firefox is probably coded to use all cores so will switch between them. the second change forces vpatch to only use one core.

ive managed to write this whole email with only about two little stutters where it didnt keep up with typing before this would have been a 5 minute typing with deleting, retyping, etc. the OS and other apps are probably still trying to use the second core a bit so there will be some hiccups. but at least my browser is usable while waiting half an hour for the patch now.

remember to set Firefox (or other) process affinity back to both cores once patching is done.

 

[the-unknown]

You should not have to set affinity for other programs during the patching procedure.

Firefox itself does not use much CPU and I doubt the patching program also uses all that much as it will probably be intensive IO with file decompression and overwriting in the hard disk.

There is something seriously wrong with the system if it takes more then 10 minutes to write even 500 MB of data.

I use a pretty recent system and patching normally take at most about 3 minutes, regardless of how big it is.

If anyone has a SSD, it may make a useful comparisson on how much IO affects patching compared to someone with a normal drive. Consider defragmenting your hard disk / making sure there is sufficient space in your drive for everything you are running (temp files / swap files / cache / etc ).

 

[aridash]

You should not have to set affinity for other programs during the patching procedure.

Firefox itself does not use much CPU and I doubt the patching program also uses all that much as it will probably be intensive IO with file decompression and overwriting in the hard disk.

i know i shouldnt *have* to set affinity, but seems to work to resolve the issues. firefox doesnt use much CPU, but if it switches to one thats under high load, its going to suffer. Decompression on the other hand is a massivly CPU intensive task, so im not at all surprised by that - just that MA have apparently desgined their code to be so agressive over other applications.

There is something seriously wrong with the system if it takes more then 10 minutes to write even 500 MB of data. [...] Consider defragmenting your hard disk / making sure there is sufficient space in your drive for everything you are running (temp files / swap files / cache / etc ).

well maybe, but i cant find it and have no other issues. if you've followed i've tried the obvious. one problem is as it downloads it fragments (as XP likes to do) so if that is the underlying issue i cant stop the patch, defrag, and strat the patch.