Re^6: Transmitting drives system load through the roof

[Andreas G. <te...@ru...>]

Christoph Bartelmus wrote 2009-04-12 21:50:

> any interrupt that comes in during transmission will destroy the timing completely
> and you will end up sending something you did not intend to send.
> It's not just waiting for the pulse or space time, as we have to generate the carrier as well.
>
> If the simple serial port transmitter design is giving you problems
> there is only one solution: don't use it.

No difference could be seen in tests with modprobe lirc_serial
softcarrier=0, which would generate pulses of visibly discernable
duration, i.e. much slower (albeit not detectable by the receiver of
the controlled device, of course, unless a hardware carrier oscillator
has been proposed and built -
http://www.lehmayr.de/PC-1360/d_hardware.htm#IR is one I could find
unrelated to LIRC).

So softcarrier=0 does NOT seem to alleviate the system load issue. As
I cannot possibly get acquainted with every aspect of your code any
time soon, I will just ask here: Will the interrupts be turned off by
lirc_serial even without the softcarrier? (And would uirt2_raw  or
mceusb have similar issues?)
Which would mean that there IS a case for the proposed approach to
leverage e.g. hrtimers with a sequence of usleeps (or whatever you
consider a suitable implementation) to avoid that kind of impact even
when baseband modulation (rather than carrier generation) is all the
transmit routine needs to do.

As things stand at least on this fairly standard PC, any user could
bring the system to its knees by just invoking irsend SEND_START
Device Command, and it is not clear whether this needs to be the case
even when using softcarrier=0 after spending some 50 cents on whatever
hardware oscillator you propose for the serial transmitter (even
though 38 kHz will not work for everything).