Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: JohnnyBob on April 24, 2008, 06:30:27 AM
-
4.8.1169
I didn't time it, but after clicking for a manual update, it takes at least a minute or two before anything happens. Then everything is in super slow motion. It eventually finishes but something is surely wrong. It was always reasonably fast in the past.
-
Your concern seems to be related to this thread (http://forum.avast.com/index.php?topic=34757.msg291722#msg291722).
If you have some actual timings we can compare then it is hard to have a discussion with "I recall" or "reasonably fast".
-
Thanks. I read the thread and didn't see any solutions. Same system here as it has been for the last few years, and always before the updates were reasonably fast. Now they're super slow. I mean if the latest update is already installed, so no update is necessary, it still takes a minute or two after pressing the update button for anything to happen. Something is wrong.
-
I guess that my point is .. the response is always instant in my case.
What evidence can you give us to take a look at.
-
The evidence is my observation that it is not working right.
-
The evidence is my observation that it is not working right.
Difficult to troubleshoot... does the update finished?
-
Read my original post.
I'm outa this stupid forum and will go back to free AVG.
Goodbye.
-
I'm outa this stupid forum and will go back to free AVG.
Well... there is no place for hard feelings. We're trying to help.
If you want you'll get it into AVG, go ahead...
-
I'm outa this stupid forum and will go back to free AVG.
Nice attitude for someone with a Peace symbol for their avatar ???
We are only trying to help you, it would have been just as easy to have said, '"It does complete, as I mentioned in my first post."
Good luck with AVG and their forums.
-
This may be too late but before you leave, how about just taking a deep breath and watch a floating cloud like this one? ;D
(http://msnbcmedia2.msn.com/j/msnbc/Components/Photo_StoryLevel/080416/080416-flogo-peace-hmed.hmedium.jpg) (http://www.msnbc.msn.com/id/24162063/)
Back on topic. 4.8.1169
I didn't time it, but after clicking for a manual update, it takes at least a minute or two before anything happens. Then everything is in super slow motion. It eventually finishes but something is surely wrong. It was always reasonably fast in the past.
Do you mean update process does not only take time but it also slows down whole the system? If so, it is definitely odd since the process may take time depending on the connection but it shouldn't be such a load on whole the system...except probably heavy program updates, which shouldn't be a case because you probably meant VPS update considering 4.8.1169 was released almost a month ago. I agree it sounds odd. I wonder how ordinarily VPS update can slow down whole the system at annoying level?
-
Rumpelstiltskin,
the process may take time depending on the connection but it shouldn't be such a load on whole the system
This is really not correct at all ... please read the explanation in the thread I linked to at the top of this thread.
-
Rumpelstiltskin,
the process may take time depending on the connection but it shouldn't be such a load on whole the system
This is really not correct at all ... please read the explanation in the thread I linked to at the top of this thread.
Probably because of my lack of understating on how Avast's VPS update works, I took it's all about program update when I skimmed the thread first time. I knew Avast's each update takes time but I thought it was the same reason for AntiVir, which seems to be suffering from the scarce server resource. Seems I totally mixed them up. Honestly, I haven't noticed Avast VPS update has been so resource intensive. Most likely I thought the slow-down was just a part of start up process since I rarely update manually.
-
I haven't noticed Avast VPS update has been so resource intensive.
And it is not... the automatic update runs at lower priority. The manual, of course, as invoked by the user himself, will run at high priority.
-
Yous beat me totally. ;D
I haven't noticed Avast VPS update has been so resource intensive.
And it is not... the automatic update runs at lower priority. The manual, of course, as invoked by the user himself, will run at high priority.
That explains a lot. So, if someone who hasn't updated VPS for a while manually updates it, then, it can be really resource intensive although the recent program tweaks are aimed to make it less problematic? Now I wonder if this is the case of JohnnyBob's...well...
-
Whether the update runs at normal priority or lower priority is not entirely relevant. The avast process of updating the virus database still is very CPU intensive (as acknowledged by the avast team) and whichever way it is run still takes exactly the same number of CPU seconds/minutes to complete.
To say it is not is simply ignoring facts.
I believe that the issue here may well be different - if we could have got more information.
The "nothing happening for a minute or two" is not normal for a manual update.
-
Just out of interest I ran two manual updates (even though my VPS is up to date) and both told me I am up to date:
1) avast on demand manual update:
Download 1s Total time 8s
2) VPSUPD.exe download
Download 3s. Total time 4s
During the first 4.8 beta I was doing a lot of restoring back to avast 4.7 (to perform comparisons with 4.8 ). What became very clear to me in that time was that if you are more than a few days behind on VPS updates it is very much faster (at least for broadband users) to download and run the VPSUPD.exe file.
-
Oh dear ... where to begin?
I have done some further testing ... and ...
Seems I may well owe an apology to JohnnyBob if he is still reading for - well at least for not asking the right questions - and I offer the apology without reservation.
Since Tech was way off the mark too maybe we can both learn something together.
I do not know how many of you reading this (even the evangelists) ever bother to pay too much attention to the avast setup log. It is rather verbose and if you are like me (and I hazard a guess this even applies to the avast team) I only pay close attention to the part that I am really interested in for any given problem.
I have tended to assume (even though reality runs counter to intuition) that avast VPS manual updates really differ hardly at all from the automatic updates. I have allowed my intuition (rather than the hard slog of detailed testing) to guide me in posting to others in the forum on this matter. While it would seem reasonable to me that the avast team would, logically, endeavor to make the differences minimal this is not the case.
I am also disturbed by the fact that the avast team have chosen not to correct the errors that both Tech and I have posted in this forum about the workings of the avast VPS updates within the past days.
If I now malign the avast team I am sure they may choose to respond but my recent testing indicates:
1) The Windows priority setting of an avast update is "Below normal" for both automatic updates and manual updates.
2) The avast automatic updates contain a parameter "/limitcpu" and that this parameter does not apply to manual updates
3) I have posted in this forum as though the /limitcpu parameter (whereby avast attempts to ensure that the CPU intensive nature of avast updates does not push CPU utilization above 30% and so ensures little or no degradation of overall system performance) applied to all VPS updates. I was wrong.
4) It is now clear that, without the /limitcpu parameter on manual updates avast.setup easily consumes >90% CPU utilization and where there is a significant update gap to be covered will severely degrade system performance.
5) The logic of restricting avast CPU utilization on automatic updates is clear. The logic, if it exists, for not applying that restriction on manual updates completely escapes me.
So, if anyone managed to stay this far:
If you have the avast VPS update settings set to manual and you are more than a few days of avast updates behind I must recommend:
1) download from the avast site and run the VPSUPD.exe file to bring you up to date (if you are on broadband by far the best option)
-or-
2) temporarily set your avast VPS update settings to automatic and wait for an update or restart your system. The avast update will automatically update and limit the use of your CPU to no more than 30%.
-or-
3) perform a manual update - go away ... clean the house, do the laundry, run your chores ... when you get back the system should be usable.
-
Whether the update runs at normal priority or lower priority is not entirely relevant. The avast process of updating the virus database still is very CPU intensive (as acknowledged by the avast team) and whichever way it is run still takes exactly the same number of CPU seconds/minutes to complete.
Seems you are right here.
The thing is, making the process priority lower is not a cure to CPU spikes. Even a process with low priority can easily take 100% CPU and all other programs will starve.
Windows is not a realtime OS, process priorities work just like hints.
It would be better to focus on what's causing the spikes.
The "nothing happening for a minute or two" is not normal for a manual update.
I missed that part since it's quite normal for automatic update: A few minutes after start-up, the notice about VPS update almost always pops up...I thought it was due to connection rather than Avast's trying not to get in the way of other processes as explained in the other thread (http://forum.avast.com/index.php?topic=34757.msg291722#msg291722), though.
I searched the boards and post some references here for someone interested.
"Saving package, this may take a while..." Question for Vlk, Igor. (http://forum.avast.com/index.php?&topic=31520)
No problem, query about some update's speed. (http://forum.avast.com/index.php?&topic=32507)
How do I configure aswServ.exe (on managed clients) to use "Normal" priority? (http://forum.avast.com/index.php?topic=21795.0)
Above, alanrf did a good job on summarizing but I think I can add something here.
5) The logic of restricting avast CPU utilization on automatic updates is clear. The logic, if it exists, for not applying that restriction on manual updates completely escapes me.
Let me make one thing clear: the CPU quota (30%) is only taking place for the automatic updates (i.e. these running on the background).
For user initiated updates, there's no restriction like this.
The rationale is that if the user invokes the update, we want to make it as fast as possible.
Cheers
Vlk
The Logic is Avast! assumes users want update when they manually update. ;D
-
Then ... I very much regret to say, as one who has also had much dealing with user's expectations, that Vlk's assumption is foolish in the extreme.
avast is only, just, nothing more than another application we choose to employ on our systems. We want it to behave in a way that does not disrupt the ability of our operating system or the general availability of our systems to run.
If it chooses to deploy itself in a way that does disrupt, against the wishes of its users, then it may join those many others - free or not - in the "whatever happened to?" list of products - much to my personal sadness.
-
The CPU limit has been inplemented because some users complained that the update started in the middle of an intensive CPU task (game) and disrupted their gaming experience. This makes some sense - as the automatic updates may start at any time, and yes, they might be a computationally intensive process if an update really takes place, it's hard to avoid.
However, if the user invokes the update manually, he is hardly just in the middle of a fullscreen game - and he's probably got a reason for the update (wants to start an on-demand scan?) So, the update is performed in the usual way.
I mean, how many programs have you seen limit their CPU usage when you start some longish operation? None? It's normal for a program to perform whatever it's asked to in the usual way, using as much CPU as needed (there's even no documented way to limit one's CPU usage, as far as I know - it's kind of a trick here). It's up to the operating system to distribute the CPU usage amongst concurrent programs, if needed.
So, I must say I'm sorry, but I don't understandat all what do you mean... Yes, avast! is just another application, so it does exactly the same as other applications do. If you ask it to perform some action, it does perform it - in the usual way. Why should it prolong the operation 3 times artificially?
Besides, all this doesn't explain the original post - on contrary, actually. The more CPU is used, the faster the manual updates should be, right?
-
I think the team's decision is rather rational, too. However, of course, as you can see, I am off and on the boards and have no idea about how many people complained of the high CPU usage issue. In my personal case, I sometimes update manually typically before system scan routine, when I close other programs due to the nature of the task. So, I have hardly noticed "the issue." The computer I installed Avast! is normally used by someone else in my family but that person hasn't complained of it, either, which is probably because I made almost everything work automatically thanks to the high flexibility of Avast! Setting. I know Avast! will do much better job than that person may do.
Besides, all this doesn't explain the original post - on contrary, actually. The more CPU is used, the faster the manual updates should be, right?
After the brief search, I have to agree they contradict if some other factors are not involved. :P :-[ Well, at least, I've learned something.
-
All that Rumpelstiltskin has to say is that the automatic update is best and that Rumpelstiltskin has very little experience of manual updates so the concurrence with the team is not surprising.
It is often the case in this forum ... opinions (good and bad) are often based on a total absence of real testing of the product. By the way the complaints about sluggish systems during avast updates were quite simply enough for avast to make a change - that speaks volumes in itself.
I have to agree that the avast recommended option of automatic updates is the best and that if you follow this sound advice you will not experience any of the issues a manual update after a gap of some time may encounter.
-
alanrf, are you in a bit melancholic mood, today? ???
All that Rumpelstiltskin has to say is that the automatic update is best and that Rumpelstiltskin has very little experience of manual updates so the concurrence with the team is not surprising.
No. I hardly says something is best. I simply says that it works fine in my case, which may or may not be special. If many people are unhappy with the current function of manual update, hopefully, the team will come up with some possible solutions. As a possible case, laptop users come to my mind since laptops are usually low on resources and portable, means, can be disconnected for a while. However, of course, I cannot speak up for them since I am in a different environment.
-
If I were to say "fine for me" then I would live a much quieter life and never object to anything in this forum.
How many people use or care about "manual updates"? I just like to take a look at problems users post here and see if there is anything to it. More often than a few times when I have I looked I too can see a problem. If I can then should I ignore it? If the avast team were to say, yes we can see that but frankly we do not believe it worth fixing then the discussion is over. I just do not want to see the valid concerns of avast users swept aside by the "it's not a problem for me" group mentality.
-
If I were to say "fine for me" then I would live a much quieter life and never object to anything in this forum.
How many people use or care about "manual updates"? I just like to take a look at problems users post here and see if there is anything to it. More often than a few times when I have I looked I too can see a problem. If I can then should I ignore it? If the avast team were to say, yes we can see that but frankly we do not believe it worth fixing then the discussion is over. I just do not want to see the valid concerns of avast users swept aside by the "it's not a problem for me" group mentality.
You took me wrong. If I objected at all, it is the extreme opinion like this one.
Then ... I very much regret to say, as one who has also had much dealing with user's expectations, that Vlk's assumption is foolish in the extreme.
For I see the team has some logic and it is based on my own experience. I see you have your own logic in your part and this is not about which is 100% right or not. This is why I see it more emotional issue rather than reasoning since emotion tends to lead us extreme opinions. I hope the team will come up with good solution to satisfy various needs. Shame that we lost the thread starter.
-
alanrf
Curiously for users with modern PC with enough memory and multicore the problem is quite opposite - why avast! is using so low CPU during manual update? It is used one core only (with up to 100% load of this core) but why 3 others are stall?
And in single core environment with low system memory assigning 'Below Normal' priority to manual updating process looks rather suspictious. It works when updater is basically sigle process consuming CPU (but in this case there is no reason for assigning this priority) or when memory is enough to avoid swapping (in this case everything should works relatively good). So the problem place is swapping presence during manual update.
-
avast has always to be concerned with the majority of its users. I doubt that the majority (especially those looking for a free solution) are yet on multi-core processors.
I am - so I suppose I would be in the "not my problem group" ... but the system I used for testing is an old single processor/512Mb system. I have even older, slower systems with less memory running avast.
As for comments about emotion ... well many of the users here expressing great frustration and threatening to storm off to another product are expressing emotion about how the decisions of the avast team affect them. That is real life. One only has to be even marginally involved in software management to know the emotions of users - just ever get anywhere near running software that users really get emotional about like their email service.
In issues like firewall and antivirus I think that, in general, users just want it to work - not slow down their system, not get in their way. It is not part of their "online personality". If it gives them grief it will be changed - it is not something they are attached to.
This is something I see in the folks I support every day.
-
Your talk in favour of users which
a) have rather old CPU;
b) low memory;
c) want to urgent VPS manual upgrage (otherwise they would use automatic one);
d) want to their system be responsible during this manual upgrage;
e) want to their AV have full VPS base detecting modern variant of malware
Are you sure that all these conditions can be fullfilled simultaneously?
For me it is not the main problem. At least it can be solved by organized measures (e.g. lauch update after ending of work or after ending of some stage of work).
The real problem is update size. Your solution (download fresh vpsupdate.exe) is absolutely inappropriate for basic part of Russia, Ukrain and so on.
For example estimated volume of daily vpsupdate.exe downloading will be 400 Mb per month. It will cost for me 60-70$ per month = 600-850$ per year. So for me it is cheaper to buy new PC every year than to use this kind of upgrade.
What would be preferred in my case?
Not solid daily vpsupdate.exe with full base, but differential one. For example vpsupdate.exe for start of current month, then updates per every week in the current month and now dayly updates per every day in current week.
Old PC problem is inner, it can be solved by user himself, he can choose to wait for update or to buy better PC.
But communication problem is outer, and it can not be solved locally. And this is a real problem in East Europe.
-
I have to ask that you do not change my posts to fit your point.
I said:
I have to agree that the avast recommended option of automatic updates is the best and that if you follow this sound advice you will not experience any of the issues a manual update after a gap of some time may encounter.
I also said:
If you have the avast VPS update settings set to manual and you are more than a few days of avast updates behind I must recommend:
1) download from the avast site and run the VPSUPD.exe file to bring you up to date (if you are on broadband by far the best option)
-or-
2) temporarily set your avast VPS update settings to automatic and wait for an update or restart your system. The avast update will automatically update and limit the use of your CPU to no more than 30%.
-or-
3) perform a manual update - go away ... clean the house, do the laundry, run your chores ... when you get back the system should be usable.
So, I gave options. I did not recommend the downloading of the VPSUPD.exe (currently 13Mb) file for every avast update in any way.
It simply escapes me why the avast manual update does not have the same limitcpu option applied to it that the automatic updates do. It would then probably not get the complaints from those performing manual updates about the sluggishness of their systems.
I do not think you were in this forum when the complaints about avast updates reached such a level that avast took some action on the automatic updates.
All we need to do now is tell those users who choose (for whatever reason) to perform manual updates that they will slow their systems more than the same automatic updates do by design of the avast team.
Isn't that all that is needed?
-
The rule of thumb: users don't read documentation. And in the case of problems complains like
I didn't time it, but after clicking for a manual update, it takes at least a minute or two before anything happens. Then everything is in super slow motion. It eventually finishes but something is surely wrong. It was always reasonably fast in the past.
are quite expected in any case.
You can see memory load, CPU load and so on to detect conditions resulting to this behaviour. But ordinary user logic is different. Simple 'Something is surely wong'.
-
Even I do not read properly ... I just had to post an apology to Vlk for not reading his post with attention.
I am still a little more puzzled about the original posters description in this thread. I wish we had got some more information.
If it is literally correct and that nothing happens for one or two minutes after requesting a manual update then it is far from usual and I cannot give any explanation to support those facts - if facts they be.
-
My 2p worth, for what it's worth.
Very interesting Alan.
I very rarely delve deeply into the setup.log, only taking a cursory look at it. Your observations are totally correct in the use of the /limitcpu parameter. I have recently cleared out my setup.log file and there was only 56KB so doing a search for /limitcpu only gets one hit and that was on the 23rd and I have had a number of updates since then. This however doesn't seem to be a VPS update but news.
So it would appear that some updates have also got past without this limitation. My Update (Basic) settings have the Virus Database set to 'Ask' so I get notification in the form of the pop-up at the bottom of the screen and I usually click that when it is displayed to do the update.
I don't know if that 'Ask' would be classed as a manual update or not (as it is initiated automatically), but if so then I wouldn't have had the single /limitcpu entry from the 23rd either. Even then I'm not sure if that single entry was for the VPS update as the command line didn't have that in it rather it had /updatenews, see below.
I did a manual update and did a screen capture of the Task Manager that shows avast.setup at 97%, giving an overall of 100% with Task Manager taking 2% and something else taking the remaing 1% to make up the 100% cpu. So on manual (and possibly 'Ask') the avast.setup happly gobbles up what ever cpu is available. During this time there is a noticable slow down in browsing, etc. but for me this isn't for that long as a) I don't have big gaps in my VPS update cycle.
Auto ? - general Cmdline: /downloadpkgs /noreboot /updatenews /verysilent /nolog /limitcpu
Manual or Ask ? - general Cmdline: /downloadpkgs /noreboot /updatevps /silent /progress
So there are other differences to the command line other than the missing /limitcpu. This difference could mean even though you have selected 'Ask' this happens automatically regardless, hence the /verysilent parameter.
Unless it is Alwil's thinking that when launching a manual update there is no need to limit the cpu activity as would appear to be the case with Igor's response. As for the comment:
It's normal for a program to perform whatever it's asked to in the usual way, using as much CPU as needed (there's even no documented way to limit one's CPU usage, as far as I know - it's kind of a trick here).
What would be wrong with applying the same trick, /limitcpu to the command line for the 'Manual' or 'Ask' form of updates.
-
Yes, even the manual updates could be run with /limitcpu parameters - but the update takes longer than "normally" in such a case (the necessary computations have to be done anyway, so if only one third of CPU is used, the computation will take three times longer).
I admit I don't have any statistics on "when people run a manual update" - but I'd expect it's done when the user wants to perform the update... "now" (for example before running a scan). So why wait for the update to finish, watch the screen... and leave the CPU idle during that time? I can't see any point here...
(It's different with automatic updates, of course - because they may be started at any time, e.g. when the user is playing a game. But here, it's the user himself who invoked the update - and probably waiting for it to finish.)
-
My whole point is I don't class what I'm doing as a true manual update but one initiated by the update check.
Being on dial-up I have it normally set to 'Ask,' now if even that is classed as a 'manual' update there are delays whilst I continue to browse whilst that update is going on.
So for me I don't class that as a true manual initiation of an update as my intention wasn't to go on-line to get any updates but to collect email, browse, these forums, etc. So the unthrottled cpu does have an impact.
Whilst the update would take three times longer it would allow me to continue with what I intended doing whilst the update effectively goes on in the background.
I don't update before a scan as I maintain my VPS updates as they become available and haven't set the Update (Basic) to Manual, so again I don't class what I'm doing, clicking the notification of update box to authorise the update as a 'manual' update.
-
Auto: /downloadpkgs /noreboot /updatenews /verysilent /nolog /limitcpu
Manual or Ask: /downloadpkgs /noreboot /updatevps /silent /progress
I don't see why we should use /downloadpkgs /updatenews /nolog options. I will keep only
/noreboot
/verysilent or /silent
/limitcpu or nothing
It is often the case in this forum ... opinions (good and bad) are often based on a total absence of real testing of the product.
Just to comment: generally, my posts refers to personal experiences and tests. If not, I based my opinions on other experiences and tests.
-
My assumption is that the /downloadpkgs parameter is essential as the downloading of the packages is what the update it about ???
My reporting of these wasn't a suggestion of what the cmdline should be, but the actual cmdline: entries from two updates from the setup.log (so there is no I would keep as that is beyond user control). One, which I though was auto (because of the /limitcpu parameter) and the other classed as manual.
-
My assumption is that the /downloadpkgs parameter is essential as the downloading of the packages is what the update it about ???
I run the command line without it... maybe it's the default action...
What is the command /stopstat that appears in some users setup.log files?
-
/updatenews is used in autoupdate when 'Program update' option is set to 'Ask' or 'Auto' only and required for chicking new program version availability.
-
/updatenews is used in autoupdate when 'Program update' option is set to 'Ask' or 'Auto' only and required for chicking new program version availability.
Not so sure... the command-line should use other parameter (right now I'm on Linux, sorry) and not /updatenews. The parameter is /program or something like that, instead of /updatevps
-
Now on Vista I've found...
"<avast>\ashUpd.exe" program /silent /nodetails
But I noticed that ashupd.exe is only present on Pro version... :-[ :-\
-
It is not ashUpd.exe. We talk about command line parameters using for starting avast.setup process in service aswUpdSv.exe (probably avast.setup is writing into setup.log)
-
It is not ashUpd.exe. We talk about command line parameters using for starting avast.setup process in service aswUpdSv.exe (probably avast.setup is writing into setup.log)
I realize that before I've posted... so my latest comment above.