Connections speed slowing down during file transfer18-Sep

1) 18-Sept-09

2) 2 days

3) MC75

4) BSP35

5) 1969037

Hello all,

We have a quite important customer and several TA's really nervous because of the following:

During a file transfer over ethernet the download speed is slowing down gradually in such a way that after some minutes you will end up with just 12Kb/s and the file will take a really long time to finish. This becomes really problematic with large files such as OS updates.

I could reproduce this easily but I have also observed that even if WiFi and USB are much faster, they also reduce the download speed during the time, however by the time you are downloading at the half of the initial speed the file is almost downloaded and this is not so problematic.

Attached are the results of the tests with some graphics that show this very clearly.

I would need to understand why this is happening and if an SPR should be open for Ethernet (the most problematic), for all the connections (all of them slow down during the transfer) or for none of them with a really good reason to put forward.

Samuel Garcia Blanco
Thank you George and Gene, I

Thank you George and Gene,

I have seen in eMscript that the CPU is always 100% when transferring files to the terminal. The latest test I did was again transferring a 50MB file using Ethernet. It took 1:54 hours!!!!! Attached are the eMScript and the wired traces regarding that transfer.

I'm almost sure that this should be addressed in a SPR but since all the connections tested (Ethernet, USB and WiFi) are significantly loosing speed gradually during a transfer I don't know if the SPR should be open for all the connection or just focus on Ethernet which is the most problematic and the one that is giving troubles to our customer.

Please advice.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Samuel Garcia Blanco
Any advice or info on this?

Any advice or info on this?

Thanks!
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


George Dellaratta
I recommend capturing a wired

I recommend capturing a wired trace of the download. 
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Gene Niles
You could trying to use a

You could trying to use a tool like emscript to see what the CPU load and free space looks like. It's possible this is application or free space related. Also try transferring directly to the RAM disk.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Gene Niles
I took a look at the logs and

I took a look at the logs and it seems a thread abclient.exe is pinning the CPU. You should try a different FTP transfer program to see if it persitst. If not, this is something that should be raised to the AB support guys.
I'm thinking the reason for the degraded thruput is due to the CPU limit being hit.Another program should may give more consistent results.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Gene Niles
actually it's a thread in

actually it's a thread in airbeam.dll which is loaded by the exe
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Samuel Garcia Blanco
After some more comparisons

After some more comparisons with different FTP clients this thread originated the SPR: 17698.

Thanks for the help provided.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Gene Niles
I added a comment to the new

I added a comment to the new SPR which we should use going forward but for the sake for closing this topic out, we should post the results of the 3rd party FTP test. Has the problem also been seen with a 3rd party client? I would be curious to know if the CPU is pinned in those logs as well.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Samuel Garcia Blanco
Hi Gene, I used " Free FTP

Hi Gene,

I used " Free FTP Client 1.1" and tested Ethernet and Wifi. In both cases the CPU was continuoslly 100% and the speed decreasing.

The logging from eMscript for Ethernet and WiFi are attached. The downloads where not finished (not time enough to wait 2h. per test) but both show the same results consistently.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Gene Niles
we ran similar tests with FTP

we ran similar tests with FTP push (via Symscript and emScript commands) and did not notice any degraded thru-put. I wonder if this is something with a pull that causes these clients to be so CPU hungry. The fact that is in a thread associated with the transfer program max's out the CPU seems to lead toward the way FTP is being implemented by the application more so than the system.

I gues this will be worked in the course of the SPR. In any case, the next logical step seems to be to use a client in which we have the total source for. This could be either Symscript or emScript.

I guess this could be addressed in the context of the SPR.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Gene Niles
let me put the corrected

let me put the corrected sentence below to something I jsut posted.
The fact that is in a thread associated with the transfer program, which max's out the CPU, this seems to lead toward the way FTP is being implemented by the application more so than the system.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Samuel Garcia Blanco
The issue shows up also using

The issue shows up also using the FTP functionality from symcript on the MC75.
I was not able to reproduce the issue on MC55, therefore, this looks platform related.

Please, find further details on the SPR,

Thanks.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments