Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Installation over serial cable
03-11-2012, 08:40 PM (This post was last modified: 03-12-2012 12:09 AM by tavvva.)
Post: #1
Installation over serial cable
I just finished a very first version of sss (Simple Serial Sender). This tool allows to pipe any amount of raw data into the serial line and then reassemble the data on the other side. It has a basic CRC check and can retry 1k sized blocks in case of CRC failure, but can't be considered absolutely reliable. Anyway, if you don't disconnect the cable, then the transfer usually succeeds. We can use this for installation over the serial cable. The former DeLi approach is more reliable, but can't be easily resurrected at the moment.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-12-2012, 12:34 PM
Post: #2
RE: Installation over serial cable
(03-12-2012 11:17 AM)Compact Wrote:  
(03-11-2012 08:40 PM)tavvva Wrote:  This tool allows to pipe any amount of raw data into the serial line and then reassemble the data on the other side.

It reminds me of dos and the norton commander to copy software via a 0-modem serial cable or the parallel port. Very usefull and unmissable for real old hardware or for newer hardware with important parts missing.

Great respect for your programming art !

I wanted to implement one of the known protocols, but as we need to transfer nearly 100MB of data (what takes over 2 hours with the highest well supported baudrate - 115200), we can't afford to lose anything on the transport protocol and thus I created my own protocol with estimated throughput efficiency exceeding 98%. We expect short and reliable cables (and thus we don't need to use absolutely reliable recovery algorithms which usually consume quite big amount of the throughput). It shouldn't be difficult to port the application to DOS or Windows. We'll see once this is released and tested by people.
At the moment I have 2 laptops with broken/missing CDROM and there's no other way to install the system there. I'd like to introduce this in 0.1-alpha3.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-12-2012, 07:14 PM (This post was last modified: 03-12-2012 07:17 PM by tavvva.)
Post: #3
RE: Installation over serial cable
(03-12-2012 07:07 PM)Compact Wrote:  
(03-12-2012 12:34 PM)tavvva Wrote:  At the moment I have 2 laptops with broken/missing CDROM and there's no other way to install the system there. I'd like to introduce this in 0.1-alpha3.

You can also get your harddrive out and connect it with a converter-adapter to another computer to do the install. But this can be pretty nasty. A soft way is safer. Your tool works with a cross linked serial cable I presume ?

Yes, that's also possible, but sometimes it's more difficult to get the converter than getting a serial cable. It's also possible to put the harddrive into a different laptop, etc. But this is really quite invasive, especially in cases when the harddrive can't be removed easily. I have some pieces where it is quite difficult. The cables are very fragile and replacement is almost impossible if you break them.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-16-2012, 08:55 PM (This post was last modified: 03-16-2012 08:59 PM by tavvva.)
Post: #4
RE: Installation over serial cable
I just found one crappy laptop that breaks the whole idea. It loses the whole input buffer with each interrupt coming from harddrive. The sss tool successfully recovered 215 errors before it finally failed after transferring 15MB of data. I'm struggling if it is a good idea to use it. I could try to resurrect the former approach, but that would only work with SLIP on the second side. TCP on top of SLIP would be more reliable in such cases. Maybe we should introduce both variants and let the user choose?
Visit this user's website Find all posts by this user
Quote this message in a reply
03-19-2012, 05:27 PM
Post: #5
RE: Installation over serial cable
I just made the former ppp approach working, but surprisingly it's less reliable! I can't believe it. That must be caused by some nasty bug in pppd / netcat / kernel. So ... it's out of the game for now. I could introduce a new input parameter (fifo size) in the sss. This parameter can make the transfer more reliable, but also much slower (15 hours) ... Sad That's hardly acceptable.
So ... I still don't know if it has a sense to reintroduce this feature ... it needs more testing.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-21-2012, 10:46 PM
Post: #6
RE: Installation over serial cable
This seems to be a kernel/module issue. I don't experience the issue with 2.6 series kernels ... needs more testing ... maybe patching ...
Visit this user's website Find all posts by this user
Quote this message in a reply
03-23-2012, 08:13 PM
Post: #7
RE: Installation over serial cable
Ok .... after more investigation this seems to be caused by different IRQ priorities .... IRQs for serial ports have lower priority than IRQs for IDE controllers .... that's why harddrive access causes buffer losses ... I still need to figure out, how to tune this ...
Visit this user's website Find all posts by this user
Quote this message in a reply
03-23-2012, 08:37 PM
Post: #8
RE: Installation over serial cable
After unmasking the harddrive IRQ the sitution got 10x better. We need to introduce irqtune and give the serial line higher priority.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-25-2012, 12:06 PM
Post: #9
RE: Installation over serial cable
irqtune seems to work only with 2.2 series kernel and older, but the unmaskirq is sufficient improvement. What's much worse is an inability of the system to transfer more than 16MB of data per one process. Reopening the descriptor doesn't help. Moreover the serial line speed is 30% lower for unknown reason. Many people noticed that, but unfortunately this issue was supposed to be fixed by the irqtune too. I'll try to workaround the issue by splitting the base file to several 10MB sized pieces and call the process several times ... this is the only reason, why 0.1-alpha3 CD is delayed ...
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)

Contact Us | DeLi(cate) Linux | Return to Top | Return to Content | Lite (Archive) Mode | RSS Syndication