MikroTik

What is "*) improved wireless TSF handling;" in the changelog mean?

What is TSF and how was it improved?

I suppose they are talking about TSF = Timing Syncronisation Function. This is implemented in 802.11 systems to ensure all participating wlan systems have a common time/clock. In systems using an AP (i.e. no ad-hoc wlans) all clients adjust their clocks to the timestamp contained in the beacons the AP sends out regularly.
This is for example important for energy saving modes. Most cards can sleep "most of the time" just waiting for a packet to arrive. For this to work, everybody on the network has to be "awake" during the same period. This is being coordinated by adjusting internal clocks by means of the TSF.

That's my understanding of it. What they actually improved I don't know - but would be interesting. I suppose that a bug/problem in TSF implementation could lead to funny problems like bandwidth drops (when stations are sleeping when they should receive a packet, which has to be re-transmitted etc.) or the like. But as I said - no clue what actually happened.

Perhaps someone from MikroTik wants to comment on it?!

Nobody from MT?

better add fragmentatation and rts to mt , i' need that features ... i must downgrade to wireless packets to 256 bytes ....

I suppose they are talking about TSF = Timing Syncronisation Function. This is implemented in 802.11 systems to ensure all participating wlan systems have a common time/clock. In systems using an AP (i.e. no ad-hoc wlans) all clients adjust their clocks to the timestamp contained in the beacons the AP sends out regularly.
This is for example important for energy saving modes. Most cards can sleep "most of the time" just waiting for a packet to arrive. For this to work, everybody on the network has to be "awake" during the same period. This is being coordinated by adjusting internal clocks by means of the TSF.

That's my understanding of it. What they actually improved I don't know - but would be interesting. I suppose that a bug/problem in TSF implementation could lead to funny problems like bandwidth drops (when stations are sleeping when they should receive a packet, which has to be re-transmitted etc.) or the like. But as I said - no clue what actually happened.

Perhaps someone from MikroTik wants to comment on it?!

So your conclusion is right, i had this problem with a PCMCIA 5213 radio and it's resolved with 2.8.25

Having serious throughput issues with 2.8.24.

The AP in question is running approximately 30-40 customers using a dual DSL backhaul link for approximately 5-6MBps. None of the customers see any issues with latency, etc ... but the perfectionist I am, I notice it.

Connected to a Netgear WG311T Atheros chipset using 802.11B or G I can barely get more than 2MB throughput. Signal level is approximately -50 to -60 and the CCQ is all over the map from 3 - 92.

We are testing the throughput by downloading large files from either a box on the mikrotik lan (going through the wireless) or downloading a large file directly from the mikrotik ftp server.

Will 2.8.25 resolve this?