Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • in reply to: extremely slow, what's wrong? #2215

    scottmayo
    Member

    Well, that’s embarrassing. I changed the termios settings to raw, used ioctl to determine how many bytes were available to read, and I stopped getting 0 byte reads. I have no idea why the sched_yield appeared to change the behaviour. Many apologies.

    in reply to: extremely slow, what's wrong? #2213

    scottmayo
    Member

    My code works by specifying a number of bytes to read and a timeout. It does a ppoll() using POLLIN | POLLERR | POLLHUP, and returns an error if that returns <= 0. Otherwise it does a single byte read (that’s all that’s guaranteed to work after a ppoll()), marks off another byte read, and if it’s not done, it recomputes the remaining time and goes around again. It’s very inefficient, but I use the same “timed read” code for sockets and other devices, not just the trueRNG, and that’s what works for sockets.

    At first I didn’t realize it was getting 0 back from read on a TrueRNG, which caused it to abandon the loop early, so I thought I was getting just a few bytes after a long wait. But the problem isn’t the rate, it’s the unexpected 0 from read.

    If ppoll() says there’s something, I should either get a character or EOF, and I wouldn’t expect an EOF from a trueRNG. I changed the code to 1) do a sched_yield before the read, which cut down the read failures (possibly to none). To be sure I also added a check for read()==0, which now simply causes a usleep(100) and goes around again. At this time all the “timed reads” work, and I don’t think it’s hitting the usleep(). I did a rpi-update recently, but sorry I can’t interrupt the code at this time to try taking out the sched_yield.

    My initial guess was some sort of confusion in some driver – this is a quad core pi and maybe some caching was mishandled in driverland. read() certainly should never return 0 after ppoll() says there’s something happening.

    I do (deliberately) turn DTR on and off around reads, just to diminish meaningless traffic, but taking that code out didn’t seem to affect the bug. For the trueRNG the code happens to ask for 384 bytes in 750ms; I would never have expected to fail.

    in reply to: extremely slow, what's wrong? #2211

    scottmayo
    Member

    I’m using ppoll to determine when data is available, and then read it. Frequently, ppoll announces that data is available but read returns 0 bytes. My code assumes that was a problem and stopped reading. The workaround is to do a sched-yield before the read. I don’t know why that helps but it does.

Viewing 3 posts - 1 through 3 (of 3 total)