Re: LCDd Command/Display Latency

On Jun 14, 2012, at 9:23 AM, Martin T Jones wrote:

> On 13/06/12 22:59, Caylan Van Larson wrote:
>> 
>> The speed I'm seeing with libusb-1.0 is definitely faster.  One out of every 20 commands I send are displayed immediately.  However, most of the time the display lags about .5 seconds, up to one second later.  This lack of real-time response makes a user-interface difficult to use.  I've tested my code and it is definitely in the display (not in the key press).
>> 
>> Jun 13 16:55:23 coposdev04 LCDd: picolcd: USB input call-back key
>> Jun 13 16:55:23 coposdev04 LCDd: Driver [picolcd] generated keystroke F3
>> Jun 13 16:55:23 coposdev04 LCDd: picolcd: USB input call-back key
>> Jun 13 16:55:24 coposdev04 LCDd: output states changed
>> 
>> The first 3 log entries above are instant.  The last one takes, quite literally, one second.
> Logging with 1 second resolution means differences may be up to a second out.
>> 
>> LCD Client Configuration
>> 
>> screen_add picolcd
>> screen_set picolcd -priority foreground -heartbeat off -backlight on
>> client_add_key -exclusively F1
>> client_add_key -exclusively F2
>> client_add_key -exclusively F3
>> client_add_key -exclusively F4
>> client_add_key -exclusively F5
>> client_add_key -exclusively Left
>> client_add_key -exclusively Up
>> client_add_key -exclusively Down
>> client_add_key -exclusively Right
>> client_add_key -exclusively Enter
>> client_add_key -exclusively Plus
>> client_add_key -exclusively Minus
>> widget_add picolcd line1 string
>> widget_add picolcd line2 string
>> widget_set picolcd line1 1 1 "Testing Line 1"
>> widget_set picolcd line2 1 2 "Testing Line 2"
>> 
>> Is there a way to tighten the main.c loop by way of main.h constants?  I understand that tightening the loop is at the expense of CPU cycles... how fast can I reasonably push it?
>> 
>>> /* You should be able to modify the following freqencies... */
>>> #define RENDER_FREQ 8
>>> /* We want 8 frames per second */
>>> #define PROCESS_FREQ 32
>>> /* And 32 times per second processing of messages and keypresses. */
>>> #define MAX_RENDER_LAG_FRAMES 16
>>> /* Allow the rendering strokes to lag behind this many frames.
>>>  * More lag will not be corrected, but will cause slow-down. */
>>> #define TIME_UNIT (1e6/RENDER_FREQ)
>>> /* Variable from stone age, still used a lot.  */
>> 
>> p.s.  Here is a little gem that, in my opinion, is extremely graceful and wonderful news for the TCP haters.
>> 
>>>   exec 0<$LCDPIPE.in
>>>   exec 1<>$LCDPIPE.out
>>>   socat STDIO,ignoreeof TCP4:localhost:13666
>> 
>> 
>> :)  Cheers!
>> 
>> (and Thank you),
>> 
>> Caylan
> 
> My system is complied with a higher process frequency (#define PROCESS_FREQ 100) which is needed to handle the IR receiver data in time but I don't remember a problem at the standard value.
> 
> I've just done a quick test and the slowest (client_set -name example) is just over 30ms.
> 
> martin@Ace:~$ socat -vlu STDIO,ignoreeof TCP4:LiFi.local:13666 2>picoLCD.log
> 
> > 2012/06/14 14:45:54.881604  length=6 from=0 to=5
> hello
> < 2012/06/14 14:45:54.889096  length=73 from=0 to=72
> connect LCDproc 0.5dev protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8
> > 2012/06/14 14:46:21.853583  length=25 from=6 to=30
> client_set -name example
> < 2012/06/14 14:46:21.884362  length=8 from=73 to=80
> success
> > 2012/06/14 14:46:32.133078  length=19 from=31 to=49
> screen_add example
> < 2012/06/14 14:46:32.137076  length=8 from=81 to=88
> success
> > 2012/06/14 14:46:47.861075  length=27 from=50 to=76
> client_add_key  -shared F1
> < 2012/06/14 14:46:47.864711  length=8 from=89 to=96
> success
> > 2012/06/14 14:47:12.741589  length=38 from=77 to=114
> widget_add example exampleTitle title
> < 2012/06/14 14:47:12.747946  length=8 from=97 to=104
> success
> > 2012/06/14 14:47:20.717590  length=48 from=115 to=162
> widget_set example exampleTitle "Example Title"
> < 2012/06/14 14:47:20.736064  length=8 from=105 to=112
> success
> > 2012/06/14 14:47:46.509084  length=27 from=163 to=189
> widget_add example i1 icon
> < 2012/06/14 14:47:46.522206  length=8 from=113 to=120
> success
> > 2012/06/14 14:47:58.929076  length=31 from=190 to=220
> widget_set example i1 1 2 prev
> < 2012/06/14 14:47:58.933163  length=8 from=121 to=128
> success
> < 2012/06/14 14:48:15.196001  length=15 from=129 to=143
> listen example
> > 2012/06/14 14:53:16.309597  length=32 from=221 to=252
> widget_add example line1 string
> < 2012/06/14 14:53:16.314173  length=8 from=144 to=151
> success
> > 2012/06/14 14:53:26.605096  length=32 from=253 to=284
> widget_add example line2 string
> < 2012/06/14 14:53:26.634674  length=8 from=152 to=159
> success
> > 2012/06/14 14:53:33.693094  length=46 from=285 to=330
> widget_set example line1 1 1 "Testing Line 1"
> < 2012/06/14 14:53:33.696917  length=8 from=160 to=167
> success
> > 2012/06/14 14:53:39.429598  length=46 from=331 to=376
> widget_set example line2 1 2 "Testing Line 2"
> < 2012/06/14 14:53:39.436049  length=8 from=168 to=175
> success

Still slow... but I'm on to something...  If I run my client and then run this keep-alive command... everything speeds up to real-time.

> X=0; while [[ true ]]; do echo noop >> /copos/dev/lcd.in; echo $X; X=$(expr $X '+' 1); sleep .1; done


Something along the way is timing out.  My hunch is socat goes to sleep and doesn't start sending again until an internal timer times out or a buffer is filled to a minimum.

If I create another fifo, and another instance of socat (another client on 13666), I can run the keep-alive but it doesn't speed up the original socat.  Hence, I think it's socat related.

I know this isn't a socat forum... but the collective lcdproc community knows much more about pipes/sockets/tcp than I do.  :-)  Thoughts?

Caylan

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc