Re: [Owfs-developers] Issue with LinkUSB dropping + baudrate test

[Roberto S. <ro...@sp...>]

Nice news :)
Maybe others tunes are possible i used other usb serial adapter anither day
with a very nice latency, i will check what chip

Em segunda-feira, 9 de junho de 2014, Johan Ström <jo...@st...>
escreveu:

>  A quick, positive (40% faster) update:
>
> I've implemented mode-toggling as described below (keep mode between
> LINK_sendback_data). This didn't give much at all, at least not with these
> small "packets".
> Since the big time-consumer is the double bytes, I dug a bit deeper and
> noticed that the byte-level read/write routines took a bit longer per byte
> than the DS2480 did.
> So, whats the difference?
>
> My DS2480 is connected via a umcs7840 based dongle.
> The LinkUSB uses a FTDI FT232R Usb-serial bridge.
>
> Quick google reveals that the FT232R chip has a latency timer which
> buffers data coming from the device to the PC. By default, this is set to
> 16ms. So I did a quick standalone program which reconfigured the FTDI chip
> using libftdi, setting the timeout to 1ms instead.
> Results:
>
> DS2480B (old reference): ~ 28ms
> LinkUSB, regular mode @ 9600, 16ms ftdi timeout: ~142ms
> LinkUSB, "smart" mode @ 9600, 16ms ftdi timeout: ~122ms (smart mode == not
> jumping to/from Send Byte all the time)
>
> LinkUSB, "regular" mode @ 9600, 1ms ftdi timeout: ~63ms
> LinkUSB, "smart" mode @ 9600, 1ms ftdi timeout: ~63ms
> LinkUSB, "smart" mode @ 19200, 1ms ftdi timeout: ~41ms
>
> So, the bottom line is:
> * Setting the ftdi latency timer shaves of a LOT of time (142->63ms)
> * Keeping track of the mode does not give much at all, it seems.
> * 19200bps gives yet ~20ms, which lands us at just 10ms more than the
> DS2480B, rather than 122ms..
>
> So, the digging was well worth the time :)
> I'll keep on experimenting, and I'll work on a proper patch (libftdi
> optional of course)!
>
> /Johan
>
> On 6/7/14 12:47 , Johan Ström wrote:
>
>
> On 6/6/14 16:23 , Johan Ström wrote:
>
> ...
> I did some speed experiments, with interesting outcome...
> This was done by manually telling the LINK to use a certain baudrate, and
> then start owserver with that setting.
>
> At 9600 bps, a full owdir (uncached) takes ~ 1700ms on my 30 devices. A
> owread on one temp sensors "power" value, takes ~100ms
> At 19200 bps, the owdir takes 1460ms and the owread ~80ms.
> At 38400 bps, the owdir takes ~1300ms.
> However, the owread fails, and renders the device inaccessible! I cannot
> get it back in working shape, without pulling the USB plug.
> Sending a break in any baudrate does not help, it won't give any response
> at all.
> I've tried both with a USB hub, and without one.
>
>  A closer look at the LinkUSB manual:
>
> --
> Key ` (single quote under ~) - Switches the device to the 38,400 baud
> serial port data rate. The host terminal will be required to switch to
> 38,400 baud before it can communicate with the LinkUSBTM further. When a
> “break” condition is detected, the LinkUSBTM resets and returns to the 9600
> baud data rate, so sending the “^” followed by more 9600 baud data will
> often find the device resetting and the speed returning to 9600 baud. See
> note (1) below
>
> ...
>
> Note 1: The 1-Wire bus with relaxed timing suitable for long lines can
> only process bits at a rate of about 14,000 per second. Streaming bytes
> using the (b) command will fail if the baud rate is set to more than 19,200
> because the host will overrun the 1-Wire bus. When the baud rate is set to
> any value greater than 19,200 the host commands must be paced to assure
> that 1-Wire bus overrun does not occur.
> --
>
>
> This could explain why it totally fails in 38400bps. The scanning works
> because it is done using link-specific commands, which would overflow the
> net. But the actual read operation fails since it overflows the bus.. Or
> does it? The note talks about the "relaxed timing" mode, which I'm not
> using.. Maybe the note is applicable to regular mode as well?
>
> Another interesting benchmark note, on a separate bus powered with an
> plain old DS2480b @ 9600bps, the same read operation takes ~30ms rather
> than ~100ms with the Link @ 9600bps.
> After adding some transaction timing, studying the manual and the
> ow_link.c source and learning a bit, I think this comes down to each byte
> requires two serial wire-level bytes (since it is read+written in hex).
> Thus, a write1 on DS2480 is write 1 wire-byte, read back 1 wire-byte. On
> the Link it becomes write 2 wire-bytes, read 2 wire-bytes, which
> effectively doubles the time required. In addition, for every sequence (32
> bytes) of bytes written, two extra command bytes are written to take the
> Link in and out of byte mode.
>
> With the simple power READ we need to do Reset(1 byte), then Match ROM
> (9), write command (1), read response(1) = 11 bytes (written + read on the
> serial level = 22b)
> On the DS2480, we're in DATA mode for the whole transaction (I think?),
> but in LINK we jump in and out of the write-byte mode for every transaction
> component (every call to LINK_sendback_data). The link thus requires
> 11*2+2+2+ 3*2 = 32 bytes instead of just 12 (11+1, we need to switch to
> data mode at least once).
> This makes the Link ~2.7 times slower, and my timings above (30 vs 100ms)
> matches this quite well, with some extra overhead.
>
> First of all, is my analysis correct?
> If so, could we not improve the speed at least a bit, by keeping track of
> the mode we're in, and avoid switching to/from byte mode all the time?
> Would not give much extra, since the majority of the bytes gets lost in the
> hex encoding, but at least a bit saved time... In combination with 19200bps
> it would be even more improvement.
> Too bad the link is not using the double-byte-encoding the DS2480 uses...
>
> Well, after going through the numbers above I realize it might not give
> enough speed gain to motivate changes... but now that I've written it down
> I might just hit send and see what you think :)
>
> /Johan
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech
>
>
>
> _______________________________________________
> Owfs-developers mailing lis...@li... <javascript:_e(%7B%7D,'cvml','Owf...@li...');>https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>

-- 
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle