discrepancy in tx_time

[Steve J]

Hi,
I am quoting this from part of specs that are
available in the document - s0005-11-light.rtf

"HREG_EV_TX :Due to the configuration of the Hermes by
the WCI, this event does not occur in WCI based Host
S/W. The meaning of this status is: "asynchronous
Transmission process is successfully completed"."

So, i guess it is not the buffering time but the
transmission time. 

Well it is still not clear why the tx_time be
influenced by the packet generation rate 
I observe follwing things, condsidering the Tx time is
measured as I meantioned in my previous mail.

For three differnect UDP applications :

1300 bytes per 10 msec -> TX_time = 100 usec
1300 bytes as fast as possible -> TX_time = 600 usec
1 bytes as fast as posible -> TX_time = 500 usec

KIndly help
regards,
-S

--- Bob Edwards <Robert.Edwards at anu.edu.au> wrote:
> 
> I haven't actually looked at the hermes code in
> quite a while, but
> I did write a device driver for the Aironet 655 ISA
> card (about 5
> years ago), so I think I might have an idea of where
> your assumptions
> are going wrong (although I am only guessing).
> 
> The Tx interrupt you are referring to is almost
> certainly generated
> once the packet has been successfully buffered for
> transmission on
> the PCMCIA card, as opposed to actually transmitted.
> At this point,
> the PCMCIA card is informing the host system that it
> has the packet
> and that the host system can now free the buffer
> etc. and start to
> send in the next packet, which will be queued for
> transmission. This
> process looks to take about 100us (for a 1300 byte
> packet) from your
> timing.
> 
> The 600us you see when you jam packets through as
> fast as possible
> is most likely the delay caused by the card
> completing the transmission
> of the previous packet, freeing its own internal
> buffers and then
> interrupting to indicate that there is now space for
> another packet
> to be loaded in.
> 
> If the data flow wasn't done this way, you would see
> much lower
> throughput through your wireless link.
> 
> Cheers,
> 
> Bob Edwards.
> 
> Steve J wrote:
> > 
> > Hi,
> > I am dong some experiments and I was just trying
> to
> > figure out the actual transmission time.
> > 
> > SO I call dogettimeofday() just before the actual
> > transmission is triggered in dldwd_xmit()
> > 
> > i.e. before - "err = hermes_docmd_wait(hw,
> > HERMES_CMD_TX | HERMES_CMD_RECL, txfid, &resp);"
> > 
> > and again call the dogettimefday() whe I receive
> an
> > interrupt from the card abt the succcessful
> > transmission.
> > 
> > I measure the interval betwen these two calls as
> > actaul trasnmission time.
> > 
> > When I start a UDP application which sends 1300
> bytes
> > packet at interval of 10msec, the tx_time come out
> to
> > be order of 100 microsecond. IT is beyond my
> > understanding how this is possible as I set the
> card
> > rate limit as 2Mbps. So given this setting the
> tx_time
> > should come out as 1300*8/2*(10^6) = 5msec
> > 
> > Also if this UDP allpicalltion sends packet as
> fast
> > as posible, i.e.without any sleeep calls(), the
> the
> > tx_time come out to be ~600 microsecond. This is
> still
> > not correct and also why should the transmission
> time
> > should change depending on the packet geneeration
> rate
> > of application ??
> > Kindly help
> > -S
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Movies - coverage of the 74th Academy
> Awards®
> > http://movies.yahoo.com/


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/