Protocol 7.00 - Slowness and solutions
7 posts
• Page 1 of 1
- cakeisalie5
- Senior Member
-
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Protocol 7.00 - Slowness and solutions
by cakeisalie5 » Fri Sep 02, 2016 8:41 am
Hello,
I have finished my CLI software to transfer files in and out the calculator, called P7 (using libp7, only available on GNU/Linux for now), one week ago, and it works fine, but I'm working on solutions to make it quicker, and as I don't know much more on protocol 7.00 than what I have found in the fxReverse projet documentation (the basics), I came here to ask if some more techniques had been found.
I'll take the simple file sending example (the file request is more tricky). For a normal packet flow (check[ini], ack, command, ack, {data, ack}, term, ack), the calculator takes ~30ms to answer each data packet. I have found out on the older transfer software (called "UsbConnector" and made by Nessotrin, part of the Planète Casio community) that he uses a special technique to make file sending quicker : he sends two initial check packets and only answers one. I have spontaneously called this technique "packet shifting" and it looks pretty dangerous (he always sends an overwrite, so he doesn't care, but as I use the protocol part about overwrite confirmation to interactively ask to the user if he wants to overwrite...), and my (few) tests didn't succeed in shifting packets other than initial check packets (which means I cannot disable it for interactive parts of the protocol then enable it for data transfer). And I haven't yet thought about how packet shifting could apply for file requesting (roleswap makes it tricky)... but results are here : the calculator takes ~3ms to answer, 10 times less.
Also, I've been told by someone using P7 (the software) that it sometimes goes really fast for him too (not always), but I've never experienced this speed increasing in my experiments. So I'm here seeking for ideas about how I could speed up the transmission (make the calculator answer faster), if someone knows a little more about packet shifting (Nessotrin didn't answer yet, but he might have gotten that idea from somewhere else), or some other techniques.
Thanks in advance
(simple log sending a 2K-large random file : )
I have finished my CLI software to transfer files in and out the calculator, called P7 (using libp7, only available on GNU/Linux for now), one week ago, and it works fine, but I'm working on solutions to make it quicker, and as I don't know much more on protocol 7.00 than what I have found in the fxReverse projet documentation (the basics), I came here to ask if some more techniques had been found.
I'll take the simple file sending example (the file request is more tricky). For a normal packet flow (check[ini], ack, command, ack, {data, ack}, term, ack), the calculator takes ~30ms to answer each data packet. I have found out on the older transfer software (called "UsbConnector" and made by Nessotrin, part of the Planète Casio community) that he uses a special technique to make file sending quicker : he sends two initial check packets and only answers one. I have spontaneously called this technique "packet shifting" and it looks pretty dangerous (he always sends an overwrite, so he doesn't care, but as I use the protocol part about overwrite confirmation to interactively ask to the user if he wants to overwrite...), and my (few) tests didn't succeed in shifting packets other than initial check packets (which means I cannot disable it for interactive parts of the protocol then enable it for data transfer). And I haven't yet thought about how packet shifting could apply for file requesting (roleswap makes it tricky)... but results are here : the calculator takes ~3ms to answer, 10 times less.
Also, I've been told by someone using P7 (the software) that it sometimes goes really fast for him too (not always), but I've never experienced this speed increasing in my experiments. So I'm here seeking for ideas about how I could speed up the transmission (make the calculator answer faster), if someone knows a little more about packet shifting (Nessotrin didn't answer yet, but he might have gotten that idea from somewhere else), or some other techniques.
Thanks in advance
(simple log sending a 2K-large random file : )
Logs: Show
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
-
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Slowness and solutions
by SimonLothar » Fri Sep 02, 2016 7:03 pm
This staggered processing seems to work indeed.cakeisalie5 wrote:I'll take the simple file sending example (the file request is more tricky). For a normal packet flow (check[ini], ack, command, ack, {data, ack}, term, ack), the calculator takes ~30ms to answer each data packet. I have found out on the older transfer software (called "UsbConnector" and made by Nessotrin, part of the Planète Casio community) that he uses a special technique to make file sending quicker : he sends two initial check packets and only answers one. I have spontaneously called this technique "packet shifting" and it looks pretty dangerous (he always sends an overwrite, so he doesn't care, but as I use the protocol part about overwrite confirmation to interactively ask to the user if he wants to overwrite...), and my (few) tests didn't succeed in shifting packets other than initial check packets (which means I cannot disable it for interactive parts of the protocol then enable it for data transfer). And I haven't yet thought about how packet shifting could apply for file requesting (roleswap makes it tricky)... but results are here : the calculator takes ~3ms to answer, 10 times less.
I had to apply only minor adjustments to my transfer program.
After sending the first data packet, the program omits the wait-loop for the first ack-packet. Instead it sends the second data-packet immediately.
While the external program sends the second data packet, the calculator simultaneously processes the first data-packet and sends the ack-packet subsequently.
After sending the second data packet, the program has to wait for the ack-packet of the first data packet a. s. o..
After the last data packet has been send, two ack-packets are to expect.
This doubles the file transfer speed on my system!
Smart idea. Well done. THX.
I'll be back!
- cakeisalie5
- Senior Member
-
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Slowness and solutions
by cakeisalie5 » Fri Sep 02, 2016 7:54 pm
Have you found workarounds for interactive parts of the packet flow (overwrite confirmation) and the passive packet flows (file requests) ? Oo
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
-
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Slowness and solutions
by SimonLothar » Fri Sep 02, 2016 9:47 pm
I use OW=02 in the ST=45-command packet (as you did in your samples). There is no interactive part involved. What workarounds do you refer to?cakeisalie5 wrote:Have you found workarounds for interactive parts of the packet flow (overwrite confirmation) and the passive packet flows (file requests) ? Oo
I'll be back!
- cakeisalie5
- Senior Member
-
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Slowness and solutions
by cakeisalie5 » Sat Sep 03, 2016 11:37 pm
Well, I would like to have this speed using this technique, to shift packets whenever I want. But I finally managed to get in touch with Nessotrin (the author of the software I took that idea off), and he answered me this (clumsy translation, I should really work on improving my english some time) :
"Well, for the duplicate packet, according to fxReverse, the start of the communication must be followed with a command giving plenty of info about the machine, I skipped it and saw the first packet always resulted in a timeout, so I've put a useless packet so it gets lost without making the program wait"
So it gave me an idea : command packet 0x01 should make packet shifting in a packet flow possible. The idea is the following : we do the interactive part (send request, omg it exists, but yes I want to overwrite, and calculator accepts), then we send the 0x01 command packet two times (shifting), send data (resend errors will surely be tricky but I should manage this using two sending buffers, alternating between them) and unshift (receive without prior sending, managing the unprobable error that could happen at this point). If I remember well, I think I tried this with a non-initial check packet, but calculator reacted in a weird way. I'll try this as soon as possible, and put the results here
EDIT: while I'm at it, here's the log with a 'meanwhile' check packet shifting (and its weird bug) :
"Well, for the duplicate packet, according to fxReverse, the start of the communication must be followed with a command giving plenty of info about the machine, I skipped it and saw the first packet always resulted in a timeout, so I've put a useless packet so it gets lost without making the program wait"
So it gave me an idea : command packet 0x01 should make packet shifting in a packet flow possible. The idea is the following : we do the interactive part (send request, omg it exists, but yes I want to overwrite, and calculator accepts), then we send the 0x01 command packet two times (shifting), send data (resend errors will surely be tricky but I should manage this using two sending buffers, alternating between them) and unshift (receive without prior sending, managing the unprobable error that could happen at this point). If I remember well, I think I tried this with a non-initial check packet, but calculator reacted in a weird way. I'll try this as soon as possible, and put the results here
EDIT: while I'm at it, here's the log with a 'meanwhile' check packet shifting (and its weird bug) :
log: Show
Part of the Planète Casio community (FR) - main author of Cahute
- SimonLothar
- Senior Member
-
- Posts: 605
- Joined: Sat Sep 15, 2012 6:59 am
- Location: Krautland ****
- Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400
Re: Protocol 7.00 - Slowness and solutions
by SimonLothar » Sun Sep 04, 2016 3:51 pm
1530 3430 3643 .0406C
The error packet 04 is not necessarily caused by an overwrite problem as designated in fxReverse.
Mannuel Naranjo and Andreas Bertheussen did their research in very early days. Possibly with fx9860 OS 1.02.
The error packet 04 is used as well, if the last sent command has been invalid.
Try the following:
Do not send any check packets between command-45-packet and the first data-45-packet.
Send the first data-45-packet immediately after the command-45-packet.
Do not wait for the ack-packet after having sent the command-45-packet.
Wait for an ack-packet after every data-45-packet.
Thus - while the calculator is processing the previous packet - you send the next packet simultaneously instead of idle waiting. That is the advantage.
After having sent the last data-45-packet wait for two ack-packets.
The error packet 04 is not necessarily caused by an overwrite problem as designated in fxReverse.
Mannuel Naranjo and Andreas Bertheussen did their research in very early days. Possibly with fx9860 OS 1.02.
The error packet 04 is used as well, if the last sent command has been invalid.
Try the following:
Do not send any check packets between command-45-packet and the first data-45-packet.
Send the first data-45-packet immediately after the command-45-packet.
Do not wait for the ack-packet after having sent the command-45-packet.
Wait for an ack-packet after every data-45-packet.
Thus - while the calculator is processing the previous packet - you send the next packet simultaneously instead of idle waiting. That is the advantage.
After having sent the last data-45-packet wait for two ack-packets.
I'll be back!
- cakeisalie5
- Senior Member
-
- Posts: 101
- Joined: Sun Mar 27, 2016 10:24 am
- Location: France
- Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50
Re: Protocol 7.00 - Slowness and solutions
by cakeisalie5 » Sun Sep 04, 2016 7:55 pm
Okay, so I took your idea of using command and first data packet to shift, but in order to accept interactive parts (that comes between command and first data packet), I used first two data packets (or only data packet and what comes right after). It works like a charm. Thanks for the idea, it was brilliant !
I'll see if I can find something similar with packet flows including roleswapping (like file requesting).
I'll see if I can find something similar with packet flows including roleswapping (like file requesting).
Part of the Planète Casio community (FR) - main author of Cahute
7 posts
• Page 1 of 1
Return to Calculator Hacking/Modding Discussions
Who is online
Users browsing this forum: No registered users and 33 guests