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
...
Microsoft Word - LinkUSB Users Guide V1.3.doc
Microsoft Word - LinkUSB Users Guide V1.3.doc 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 list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
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
