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...@stromnet.se>
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 listowfs-develop...@lists.sourceforge.net
> <javascript:_e(%7B%7D,'cvml','Owfs-developers@lists.sourceforge.net');>https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
--
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
