On Tue, 19 Jul 2022, 19:01 Kiran Shila, <[email protected]> wrote: > > ?wordread/?wordwrite was written with maximal human readability in > > mind. Somebody who has a misbehaving roach deployed somewhere can just > > telnet/netcat/socat/etc to port 7147 and issue a wordread > > to see if enough bits are toggling, or if some counter is ticking > > over, set a debug flag, etc. > > I would've just used `wordread/write` but as of the latest version of > the Raspberry Pi image, that functionality is broken. I tried updating > to the latest version of katcp_devel (75dde9d), but then nothing worked > at all. >
It seems like the easiest way to make everybody satisfied is to fix the above issue, which is a) objectively broken, not "just" non compliant; b) absolutely cannot possibly be that hard to fix. (Take the snap/pi version of tcpborphserver, find the "actual" fpga read/write call within the wordwrite/ wordread command, and replace it with an appropriate SPI call) My caution: if you do this and only use these commande, all moderate sized read writes will be annoyingly slow. > > ?read/?write are intended to retrieve larger chunks of data, > > and use a represenation which is reasonably efficient. The link > > to the powerpc isn't particularly fast, and while there are things > > that could be optimised further, the current backslash encoding isn't > > computationally expensive and adds a bit over 3% overhead, > > which I think is reasonably good. > > Why does it need to be efficient? Especially considering in other parts > of the codebase we're bit-banging SPI through katcp messages (which is a > single bit for a 28 byte message, a cool 0.45% efficiency) > And it's terribly slow! The only reason noone complains is that they don't realise it could trivially be an order of magnitude faster! As to the _need_ for efficiency, I guess its a question of what the practical implications of some other encoding would actually be, but there are use cases where multiple GBytes of data are moved through katcp, and people care about it being fast. Sometimes it directly impacts science objectives like how fast you can dump a spectrometer. Maybe / probably they don't care at the few-% of overhead level, but certainly some moderate level of efficiency is required by practical use cases. > > When I was referring to escape (and cornered programmers) in the > > previous mail I didn't only mean literal escape characters, > > but also a means to escape some of the constaints or access > > extended functionality. In the above case, binary(ish) data to > > do more efficient bulk transfers. > > But again, was there an actual problem this was solving? Was there a > throughput issue somewhere that required spec-breaking changes? For bulk > transfer (like uploading the FPG file), this was solved with opening a > separate TCP connection and streaming bytes that way. > I can tell you concretely that there absolutely does need to be a bulk data transport mechanism. Wordread and wordwrite alone aren't acceptable. They're way too slow. So, that is/was the problem to be solved. Could the problem have been solved without breaking the ascii requirement - sure. Why was it not? I don't know. Changing the tcpborphserver behaviour of read/write in a way that is not backwards compatible with casperfpga (and every other preexisting casper katcp client) seems unlikely to me to be a goer. Obviously you could do it to meet your needs/desires, but this code isn't going to ever get merged into the main repos/branches (you might reasonable ask whether this matters, given how many distinct, incompatible code branches are already lying around). In any case, making new bulk transfer commands which are compliant, and work with the client you're building seems like a path which should keep everyone happy(?) > > Of course, there is also nothing stopping you from only > > using ?wordread and ?wordwrite in your rust library if the ?read and > ?write > > requests strike you as suffiently awkward. > > Besides the commands being broken, it's not just awkward to use `read` > and `write`, it's not valid katcp. It will not parse with the formal > grammar given. Having messages that break the contract defeats the whole > purpose of having a formal specification. > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/63df8a5b-c1d8-6fd7-eed0-7d56ee2af203%40kiranshila.com > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSn6ZrEknTdvKQMUXF2d5BjftwCpKrBfEq6Eh%3D-YYPtapw%40mail.gmail.com.
