ARM7->ARM9 latency problem

[sgstair]

I've implemented a simple TFTP-server that I'm going to use for a project later. TFTP works by sending one DATA packet, wait for ACK, send next DATA, and so on. This means only one packet is in the queue at any time and therefore the protocol is very sensitive to latency.

 

I've only gotten about 5 kb/s transfer rates. I've discovered that the bottleneck is the communication between the ARM7 and the ARM9 processors. The ARM9 polls for new packages every 50 ms, when the Wifi_Timer_50ms() function is called. That means new packages are recieved 10 times every second. Since TFTP sends 512 bytes in every package you only get a transfer rate of 10 * 512 ~ 5 kb/s.

 

This leads me to two questions:

 

1. Why is it using polled communications between the processors when the IPC interrupts could be used?

 

2. Why is the IP stack implemented on the ARM9 processor and not ARM7? It would be much more efficient if I could implement the TFTP-server in ARM7... The socket functions could be made available on both processors using IPC for ease of use.

 

And another question:

 

3. In wifi_lib_test TIMER3_DATA is set to -13106. Doesn't that give an interrupt every 100 ms instead of 50 ms?

 

PS. using wifi_lib 0.2b

<{POST_SNAPBACK}>

 

Ack! didn't notice this thread

1) to not interfere with whatever the end user wanted to do. there *will* be support for instant notification via IPC in the next version.

2) ease of use, speed, etc... It was a design decision.

3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion

 

-Stephen

[Stonebone]

3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion

<{POST_SNAPBACK}>

The ARM9 cpu is running at 33.514 MHz. The divisor is set to 256 gives us (33.514*10^6 / 256)^-1 ≈ 7.6*10^-6 s per tick. Then we have 13106 * 7.6*10^-6 ≈ 0.100 s. This is how I understand that the timers work anyway, I might be wrong.

[Stonebone]

I've released tftpds 1.0. See my new page: http://www.itstud.chalmers.se/~larssten/nds/

[sgstair]

3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion

<{POST_SNAPBACK}>

The ARM9 cpu is running at 33.514 MHz. The divisor is set to 256 gives us (33.514*10^6 / 256)^-1 ≈ 7.6*10^-6 s per tick. Then we have 13106 * 7.6*10^-6 ≈ 0.100 s. This is how I understand that the timers work anyway, I might be wrong.

<{POST_SNAPBACK}>

Indeed- I must have misread this somewhere or something. I'll fix it in the next release.

 

-Stephen

[jfperusse]

I've implemented a simple TFTP-server that I'm going to use for a project later. TFTP works by sending one DATA packet, wait for ACK, send next DATA, and so on. This means only one packet is in the queue at any time and therefore the protocol is very sensitive to latency.

 

I've only gotten about 5 kb/s transfer rates. I've discovered that the bottleneck is the communication between the ARM7 and the ARM9 processors. The ARM9 polls for new packages every 50 ms, when the Wifi_Timer_50ms() function is called. That means new packages are recieved 10 times every second. Since TFTP sends 512 bytes in every package you only get a transfer rate of 10 * 512 ~ 5 kb/s.

 

This leads me to two questions:

 

1. Why is it using polled communications between the processors when the IPC interrupts could be used?

 

2. Why is the IP stack implemented on the ARM9 processor and not ARM7? It would be much more efficient if I could implement the TFTP-server in ARM7... The socket functions could be made available on both processors using IPC for ease of use.

 

And another question:

 

3. In wifi_lib_test TIMER3_DATA is set to -13106. Doesn't that give an interrupt every 100 ms instead of 50 ms?

 

PS. using wifi_lib 0.2b

<{POST_SNAPBACK}>

 

Ack! didn't notice this thread

1) to not interfere with whatever the end user wanted to do. there *will* be support for instant notification via IPC in the next version.

2) ease of use, speed, etc... It was a design decision.

3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion

 

-Stephen

 

1) Is it in the current version? The hacked dswifi link is not working anymore. What are the changes required in the wifi lib???

Edited September 17, 2006 by jfperusse