Please Remember To Fix The Outbound Email Scanning Problem

Avast Free Antivirus / Premium Security
21

With scanning enabled, the mail client seemed to stop responding (it still sent mail). The first time I tried it, it froze NetPerSec. I then rebooted and tried again - only got about 35KBS. Then when I tried to save the test mail, mozilla hung.

Thanks,
Harvey

22

…must’ve been because of the 100% CPU usage the new ashMaiSv.exe was using during data transfer (because of its attempt to maximize the throughput).

Here’s the last version: http://www2.asw.cz/misc/ashmaisv2.zip – if that doesn’t help, I must be dreaming (because it IS changing the speeds here - and very noticably).

Thanks for your help (and I’m really sorry for the hassle - I’m getting the impression that you’re now incllining to NAV anyway… :-).

Cheers
Vlk

23

O’K., this IS different!

  1. With scanning disabled, I still only get around 80KBS.

  2. However, now, with scanning enabled I am averaging close to the 92KBS that I see with NAV 2004. However, the speed as a function of time is very “spikey” (using NetPerSec) - that is, I will see lows of around 30KBS followed by highs of around 134KBS. The average appears to be around 92KBS.

This is worth further experimenting with.

Can you elaborate on what you did and why it is working as it is?

Thanks,
Harvey

24

Well, I spoke too soon. After rebooting back into win xp, I recieved a message indicating Avast had to reload my OS. I rebooted and now with scanning enabled, I’m back to the same 35KBS speeds.

Harvey

25

Oh yeah, the auto-updater replaced the patched file with its original version (as a security measure).
What version of avast do you have installed, exactly? Do you have the latest one - 4.6.665?

Thanks
Vlk

26

Wait, wait, wait. I thought I had the latest version - but I have 4.6.652. I redid the patch and I was back to the 92KBS (erratic) average, so the reboots must have clobbered the changes I will update to the latest version and redo the patch and get back to you.

Thanks,
Harvey

27

Vlk,

could not resist trying the lastest patch you offered to hgratt.

Interesting -

My test message has varied in delivery time only between 87-90 seconds with Avast turned off, well within the variations of Comcast - my (and hgratt’s) cable provider.

With the lastest patch, from hitting send to completion the result was 100 seconds.

Allowing for the fact that I have reported before that it is taking 8-9 seconds to create the temporary cache (in the case of Thunderbird) and less than two seconds in the case of OE, it seems to me that you have just about matched the transmisson speed of Thunderbird.

28

hgratt: OK, let me explain what’s up.
The ZIP file (the patch) contains two files - a .DLL and a .DLL.SUM.

The .DLL is the patch itself (the binary). The .DLL.SUM is a special file that is telling the avast updater that this is an authorized patch (otherwise, it would get replaced by the original version - this is part of the defensive strategy built-into avast to fight with unauthorized changes caused by malware).

However, the authorization is bound to a specific version number. This is because when a new version is installed, we want the patch to be updated by a new version.
And, the .DLL.SUM file in this particular ZIP file is for version 4.6.665 (so you need to have this version installed for the DLL.SUM file to be effective).

Hope this helps,
Vlk

29

Vlk,

the result for the same message when using OE was 92 seconds compared with 130 seconds yesterday.

So, you have made sending mail by OE scanned with Avast much faster than sending it without scanning … you should sell it to the folks in Redmond!

30

;D

There’s really no rocket science here. I changed only two things:

  1. increased the chunk size (the size of data sent at once) from 8KB to 128KB
  2. removed the sleep command after sending each chunk.

That is, there were artificial sleeps (delays) implemented in the code - I don’t know why yet (I’ll have to ask the developer responsible for this code tomorrow).
It’s possible they were there for a reason - but I’d say the main reason was to prevent excessive CPU loads for the ashMaiSv.exe process…

Thanks
Vlk

31

Hmmm … just in line with what I suggested was happening in the original thread Harvey created on this issue.

Thanks for being upfront about the issue - it is appreciated.

32

Just one more thing, can someone check the difference in the creation of the temporary cache file between Mozilla code and OE?

Unless there is some oddity in the Mozilla code, it should not take 8 seconds to cache the same amount of data from Mozilla as it takes less than 2 seconds from OE.

33

I updated the program and it now works on subsequent reboots. Looks like we’re making progress. Again, the speed averages around 90-92KBS, but is quite erratic.

Based on your explanation as to what you did, it sure seems that many people should see this issue - not just alanrf and myself.

Anyway, at least the area of concern seems to be identified. Maybe some further optimization will “smooth” out the upload speed.

Thanks,
Harvey

34

Erratic? Or just uneven?

35

Uneven. Speed bounces back and forth from lows of 30KBS to highs of 135KBS.

Harvey

36

Isn’t it a bit strange? I mean, considering that the maximum speed of your line is < 100KB/s (physically), isn’t it a problem in the way NetPerSec does the measurements?
I was using LanSpeed2 to check the speed and I didn’t see any anomalies…

Thanks
Vlk

37

I think only the average speed is constrained.

Do you have a copy of LanSpeed2 that I could try?

Harvey

38

http://www.tucows.com/get/259303_100243

39

O.K., I set the interval for 1 sec (same as NetPerSec) and the line graphs show the same uneven behavior and same average speed.

BTW, I really appreciate all the time and effort your putting into this. Hopefully, this will benefit everyone.

Harvey

40

I’d say it’s because ashMaiSv.exe is yielding to other processes for a short while after sending each chunk of data (128KB)…
I don’t think there’s a problem.