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.
After the brief search, I have to agree they contradict if some other factors are not involved. :-[ 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? ???
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.
You took me wrong. If I objected at all, it is the extreme opinion like this one.
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:
[b]If you have the avast VPS update settings set to manual and you are more than a few days of avast updates behind[/b] I must recommend:
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-
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-
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.
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.
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.
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.
/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
:-[ Well, at least, I’ve learned something.