Hi,
calculating the time taken to transmit each packet, given the information
available in minstrel, is very small. This will not alter the final
throughput.
There is some queing delay, but this only happens when there
are more packets to send than there is time to send them.. This will
happen if the application puts a hundred (or some such large number)
packets to a network socket for transmission. In this case, I think the
linux kernel will hold the packets, waiting for the right time to put them
to the driver. The driver takes each packet as it is ready, and sends
them. The time required to transfer the packets from the linux network
stack to the transmission queue is minimal, and should be ignored.
The time required to transmit a packet (which is derived from the 802.11
acknowledgement packet, which is is available inside minstrel) maybe
anything from 100s of microseconds to 24 ms. This time tells you much
about the status of the link between the sending and recipient nodes.
Derek.
On Tue, 26 Jan 2010, Xingang Zhang wrote:
Again, I appreciate your insightful thought and input. I heard that
using current rate and the number of bytes sent in each packet, you
can derive the transmission time. I am wondering if it's feasible to
"timestamp" every packet so that we can get the transmission delay,
queuing delay, etc. by retrieving the difference between the
timestamps that each packet piggyback?
I understand that this extra work may lower the final throughput of
the wireless card. However, if that's not too bad (10-15%), it's still
acceptable.
Any thought?
Thanks
On Tue, Jan 26, 2010 at 5:59 PM, Derek Smithies <de...@indranet.co.nz> wrote:
Hi,
Presumably, you are using the minstrel rate algorithm. This is the default
rate algorithm in the linux kernel, and works well.
I suggest you add code to minstrel to process the feedback from radio. This
will tell you how successful it was to transmit a packet, and how many
attempts were required. From this information, you can "derive" the time
taken to transmit the packet.
Derek.
On Tue, 26 Jan 2010, Xingang Zhang wrote:
Thanks for your quick reply. It's really helpful.
You know, I am trying to compare the timestamp of each packet and
measure the sum of transmit delay and queuing delay. with so small
round up time, it looks like I can not use this one from the
ath5k_tx_status.
Any better idea?
Thanks.
Ethan
On Tue, Jan 26, 2010 at 2:25 PM, Derek Smithies <de...@indranet.co.nz>
wrote:
Hi,
ts_tstamp is the lowest 16 bits of the 64bit timestamp.
The time is in microseconds, so ts_tstamp wraps round every 32.768ms.
The 64bit timestamp wraps around every 580 000 years
ts_tstamp is from the 64bit timestamp from the radio card, and is totally
different to jiffies from the kernel.
Derek.
On Tue, 26 Jan 2010, Xingang Zhang wrote:
Hello,
I am wondering how to interpret the meaning of ts_tstamp? I can tell
it's u16 from hardware, but have no idea how to compare that with the
value of jiffies or some other time from kernel.
Thanks for any input.
Best,
Ethan
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
