Menu
▾
▴
owfs-developers
|
From: Johan S. <jo...@st...> - 2014-06-05 11:53:03
|
Hi, I got a LinkUSB as a master for my 1-wire net, around 80m with 30 devices. The bus is scanned every minute and temperature sensors polled (most of the devices). Around 3 times a second I try to scan the alarm dir for alarms (DS2406's), and possibly handle these. Normally this works perfectly fine, and has done so for a few years. No re-reads or CRC errors according to the counters. However, a few times during these years, the whole network has become inaccessible, and the only way to get it back into working shape has been to unplug the LinkUSB from both the 1w-network (DQ+DGND), and the USB port. Once doing this, it all comes back up immediately, and all devices work fine. If I recall correct I have also pulled the external 5V feed to the devices too, but just disconnecting the 1w-network from the LinkUSB, and disconnecting the 5V feed has NOT been enough, the USB port must be disconnected as well. Restart of owserver does not help. Anyone else with similar experiences, or ideas on what might be causing this or how to work around it? Hard to debug since I cannot really reproduce it at will.. Thanks Johan |
|
From: Stefano M. <mo...@ic...> - 2014-06-06 07:21:04
|
the LinkUSB is a serial over USB adapter: can you rule out USB problems?
I have a LinkUSB connected to a very old server running Linux and sometimes the device gets "disconnected":
[ 1.808165] usb 1-5.2: new full-speed USB device number 4 using ehci_hcd
[ 1.906558] usb 1-5.2: New USB device found, idVendor=0403, idProduct=6001
[ 1.906563] usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.906566] usb 1-5.2: Product: FT232R USB UART
[ 1.906569] usb 1-5.2: Manufacturer: FTDI
[ 1.906572] usb 1-5.2: SerialNumber: XXXXXXXX
[ 6.601905] usb 1-5.2: Detected FT232RL
[ 6.601908] usb 1-5.2: Number of endpoints 2
[ 6.601912] usb 1-5.2: Endpoint 1 MaxPacketSize 64
[ 6.601915] usb 1-5.2: Endpoint 2 MaxPacketSize 64
[ 6.601918] usb 1-5.2: Setting MaxPacketSize 64
[ 6.602420] usb 1-5.2: FTDI USB Serial Device converter now attached to ttyUSB0
...
[529298.815921] usb 1-5.2: USB disconnect, device number 4
[529299.340167] usb 1-5.2: new full-speed USB device number 5 using ehci_hcd
[529299.438420] usb 1-5.2: New USB device found, idVendor=0403, idProduct=6001
[529299.438425] usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[529299.438429] usb 1-5.2: Product: FT232R USB UART
[529299.438432] usb 1-5.2: Manufacturer: FTDI
[529299.438435] usb 1-5.2: SerialNumber: XXXXXXXX
[529299.441024] usb 1-5.2: Detected FT232RL
[529299.441027] usb 1-5.2: Number of endpoints 2
[529299.441030] usb 1-5.2: Endpoint 1 MaxPacketSize 64
[529299.441034] usb 1-5.2: Endpoint 2 MaxPacketSize 64
[529299.441036] usb 1-5.2: Setting MaxPacketSize 64
[529299.441403] usb 1-5.2: FTDI USB Serial Device converter now attached to ttyUSB1
...
[1016813.881513] usb 1-5.2: USB disconnect, device number 5
[1016814.412250] usb 1-5.2: new full-speed USB device number 6 using ehci_hcd
[1016814.510375] usb 1-5.2: New USB device found, idVendor=0403, idProduct=6001
[1016814.510380] usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1016814.510384] usb 1-5.2: Product: FT232R USB UART
[1016814.510387] usb 1-5.2: Manufacturer: FTDI
[1016814.510390] usb 1-5.2: SerialNumber: XXXXXXXX
[1016814.513109] usb 1-5.2: Detected FT232RL
[1016814.513113] usb 1-5.2: Number of endpoints 2
[1016814.513116] usb 1-5.2: Endpoint 1 MaxPacketSize 64
[1016814.513120] usb 1-5.2: Endpoint 2 MaxPacketSize 64
[1016814.513123] usb 1-5.2: Setting MaxPacketSize 64
[1016814.513478] usb 1-5.2: FTDI USB Serial Device converter now attached to ttyUSB0
So here you see that once a week or so my linkUSB is disconnected and "rediscovered", which means that I have the linkUSB bouncing between /dev/ttyUSB0 and /dev/ttyUSB1. I have no idea who is responsible of this behaviour (the server USB adapter? the linkUSB? the Linux kernel?)
I solved the problem with a custom udev rule, which creates a /dev/linkUSB0 symlink to the current /dev/ttyUSBx device.
SUBSYSTEM=="tty", \
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="XXXXXXXX", \
SYMLINK+="linkUSB0", GROUP="owfs"
where of course you have to substitute XXXXXXXX with the actual serial number. BTW I also set the group to "owfs" instead of "dialout" since I do not run owserver as root but as a user belonging to the group, you guess, "owfs".
S.
On 05 Jun 2014, at 13:52, Johan Ström <jo...@st...> wrote:
> Hi,
>
> I got a LinkUSB as a master for my 1-wire net, around 80m with 30 devices.
> The bus is scanned every minute and temperature sensors polled (most of
> the devices). Around 3 times a second I try to scan the alarm dir for
> alarms (DS2406's), and possibly handle these.
>
> Normally this works perfectly fine, and has done so for a few years. No
> re-reads or CRC errors according to the counters.
> However, a few times during these years, the whole network has become
> inaccessible, and the only way to get it back into working shape has
> been to unplug the LinkUSB from both the 1w-network (DQ+DGND), and the
> USB port.
> Once doing this, it all comes back up immediately, and all devices work
> fine.
>
> If I recall correct I have also pulled the external 5V feed to the
> devices too, but just disconnecting the 1w-network from the LinkUSB, and
> disconnecting the 5V feed has NOT been enough, the USB port must be
> disconnected as well. Restart of owserver does not help.
>
>
> Anyone else with similar experiences, or ideas on what might be causing
> this or how to work around it? Hard to debug since I cannot really
> reproduce it at will..
>
> Thanks
> 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
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
|
|
From: Johan S. <jo...@st...> - 2014-06-06 14:24:10
|
Thanks for that tip, I checked the logs but it was not "unplugged" until I actually unplugged it to fix the problem. I have a similar devd-setup (see 1) for FreeBSD conf) to solve the device-name-jumping problem. It doesn't always change name, but sometimes it seems to.. So, I'm quite certain that was not the case. However, I got an off-list tip from the author of a previous thread (http://sourceforge.net/p/owfs/mailman/message/31750321/) , which addresses the issue that the LinkUSB has support for multiple baud rates, but owfs only tries to init with 9600bps. The explanation would be that the LinkUSB somehow jumps into another baudrate, and owfs then fails to connect to it. I cannot really say for sure that this is what happens, until I get one of these lockups again so I can analyze it further. A test which proves that owfs does indeed fail to handle other baudrates, as described in the previous thread: First tell the LinkUSB to set the speed to 19200: $ cu -l /dev/cua-linkusb -s 9600 (write space to get "LinkUSB V1.5", write , (comma) to move to 19200) $ cu -l /dev/cua-linkusb -s 19200 (write space again to verify 19200 is active) Start owserver, and it won't find the device at all, since it only tries 9600bps. Only solution is to either switch back to 9600 manually, or power-cycle the device. I did some patching, also based on Arne's suggestions in the previous thread, to improve the detection situation. In addition to his changes, this tries all speeds with all flow-control modes, and also supports Globals.baud to set the initial speed: https://github.com/stromnet/owfs/commit/478389a97d71d76e31e4d3c913eca4397ec6a375 As the todo note indicates, I'd like to add the ability to change the LINKs speed from within owfs. 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 note about USB power-cycling, I tried to power it down using usbconfig: usbconfig -d ugen4.2 power_off usbconfig -d ugen4.2 power_on The kernel detects the device as disconnected, and reconnects it on power on. But it still won't wake it up from the dead. Only unplugging it helps in the above scenario. To summarize: Could my sporadic problems be related to baud-rate changes? From what I read in the code, owfs does not change baud-rate by itself, so that would mean it changed by some glitch. But if it is changed, owfs would not find the device without the patch above, until it is power cycled. On the other hand, the 38400bps test proves that the LinkUSB can go into some kind of crashed mode, where it does not respond at all. If this is what happens, the baud-rate patch wont help. Using higher baud-rate between the host and the device shows some, although small, performance improvements. ~15% on the scan, and 25% on the read when speed was doubled. Quite strange that it crashes on 38400 though, the device advertises both 38400 and 57600bps.. Johan 1) For the record, my /usr/local/etc/devd/linkusb.conf: attach 10 { device-name "uftdi[0-9]+"; match "vendor" "0x0403"; match "product" "0x6001"; match "sernum" "XXXXXXXX"; action "logger LinkUSB attached on $cdev/$device-name/$sernum/cua$ttyname, creating symlink and setting owner. ; /bin/ln -fs /dev/cua$ttyname /dev/cua-linkusb; chown owfs /dev/cua-linkusb"; }; On 6/6/14 09:20 , Stefano Miccoli wrote: > the LinkUSB is a serial over USB adapter: can you rule out USB problems? > > I have a LinkUSB connected to a very old server running Linux and > sometimes the device gets "disconnected" > So here you see that once a week or so my linkUSB is disconnected and > "rediscovered", which means that I have the linkUSB bouncing between > /dev/ttyUSB0 and /dev/ttyUSB1. I have no idea who is responsible of > this behaviour (the server USB adapter? the linkUSB? the Linux kernel?) > > I solved the problem with a custom udev rule, which creates a > /dev/linkUSB0 symlink to the current /dev/ttyUSBx device. > > SUBSYSTEM=="tty", \ > ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="XXXXXXXX", \ > SYMLINK+="linkUSB0", GROUP="owfs" > > where of course you have to substitute XXXXXXXX with the actual serial > number. BTW I also set the group to "owfs" instead of "dialout" since > I do not run owserver as root but as a user belonging to the group, > you guess, "owfs". > > S. > > On 05 Jun 2014, at 13:52, Johan Ström <jo...@st... > <mailto:jo...@st...>> wrote: > >> Hi, >> >> I got a LinkUSB as a master for my 1-wire net, around 80m with 30 >> devices. >> The bus is scanned every minute and temperature sensors polled (most of >> the devices). Around 3 times a second I try to scan the alarm dir for >> alarms (DS2406's), and possibly handle these. >> >> Normally this works perfectly fine, and has done so for a few years. No >> re-reads or CRC errors according to the counters. >> However, a few times during these years, the whole network has become >> inaccessible, and the only way to get it back into working shape has >> been to unplug the LinkUSB from both the 1w-network (DQ+DGND), and the >> USB port. >> Once doing this, it all comes back up immediately, and all devices work >> fine. >> >> If I recall correct I have also pulled the external 5V feed to the >> devices too, but just disconnecting the 1w-network from the LinkUSB, and >> disconnecting the 5V feed has NOT been enough, the USB port must be >> disconnected as well. Restart of owserver does not help. >> >> >> Anyone else with similar experiences, or ideas on what might be causing >> this or how to work around it? Hard to debug since I cannot really >> reproduce it at will.. >> >> Thanks >> 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 >> Owf...@li... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > ------------------------------------------------------------------------------ > 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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
From: Johan S. <jo...@st...> - 2014-06-07 10:47:32
|
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 |
|
From: Roberto S. <ro...@sp...> - 2014-06-10 00:02:11
|
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 |
|
From: Johan S. <jo...@st...> - 2014-06-11 21:21:51
|
Quick report: I have successfully implemented libftdi support in owfs now, it works but a few things to polish up, such as retry handling etc. A question regarding LinkUSB: have you gotten the "BREAK" functionality to work? From the manual: -- Key , (comma) - Switches the device to the 19,200 baud serial port data rate. The host terminal will be required to switch to 19,200 baud before it can communicate with the LinkUSBTM further. When a "break" condition is detected, the device 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. -- I haven't been able to reset to 9600 besides doing a power-on reset... I've tried sending break through 'cu', through tcsendbreak, and through libftdi, without any success. It simply ignores it, and keeps at 19200. Kind of makes the startup procedure trickier, since we cannot force it to 9600 and work from there.. Anyone who have success with break? On 6/10/14 01:55 , Roberto Spadim wrote: > 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... > <mailto: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 > |
|
From: Johan S. <jo...@st...> - 2014-06-09 22:10:44
|
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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X