On Tue, 17 Oct 2017, Angelo Dureghello wrote:
On 16/10/2017 01:08, Finn Thain wrote:
On Sun, 15 Oct 2017, Angelo Dureghello wrote:
Hi all,
i was trying a file transfer with xmodem-1k and uClinux "rx" on the
mcf54415 stnmark2 board side.
This using a recent mainline kernel:
/ # cat /proc/version
uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d
/ #
So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and
2 bytes crc16. But "rx" timeouts waiting the block.
What is the fastest baud rate that will work?
Adding some traces to "rx", it timeouts since some bytes (5 to 10)
randomly positioned in the block are not received. Of course they
have been sent (scope checked).
The same 1024 bytes transfer in u-boot (y-modem) always succeed.
Does u-boot need to do any retransmissions? (If it polls the UART, it
could probably avoid any fifo overflow.)
You may also want to try lrzsz.
Since mcf54415 has a 4 slots RX fifo UART,
Ouch. At 115200 baud, that FIFO overflows after about 347
microseconds. If the kernel takes one interrupt per 4 bytes, you're
looking at thousands of interrupts per second. Add a little unexpected
interrupt latency (say, 50 microseconds) and the next byte gets lost.
I should have said "86 microseconds", to guarantee an overflow, but the
margin is lower than that even on an idle system, because time is lost in
interrupt dispatch. This margin is the same whether the interrupt happens
after one byte or four bytes.
thanks for explaining this.
Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags
that can be checked: RXRDY, for one or more character received (current
mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full.
So we probably have even more interrupts per second right now.
Even if you can reach 4 bytes per interrupt, the payoff is probably a
reduction in CPU overhead due to interrupt load rather than a reduction in
FIFO overflows.
There seems to be too much interrupt latency to support the line rate.
(Was that x-modem file transfer going to a storage device? Perhaps try
sending it to tmpfs or /dev/null.) A line rate of 38400 or 57600 baud is
probably more realistic.
I am at 115200, will try to decrease, and also, will try zmodem in case.
You could try transmitting a large number of bytes at full speed, counting
them at the receiving end, and counting the number of interrupts from IRQ
source 90 using /proc/interrupts. The bytes per interrupt ratio may
already exceed 1, so the benefit from adopting the FFULL interrupt may not
be what you expect.
--
Regards,
Angelo
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
