[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] coldsync 1.5.3 nov 27 snapshot
Well, thank you kindly for getting that fixed. :-)
However, i've noticed another problem: USB is going really really slow.
I've got a .coldsyncrc like:
listen serial {
device: /dev/ttyUSB1;
speed: 115200;
}
(i've also tried 57600 and 230400)
And it would still take forever to do the backup or install of a few
hundred K.
So, i tried with debug mode - `coldsync -mr my_files -dsync:3`
and it gave me something this
(pretty much regardless of what I had the speed set to):
Using default speed (38400 bps)
-> Setting speed to 38400 (15)
Once I got it to be:
-> Setting speed to 115200 (4048)
(or something very similar), but that wasn't reproducible.
I also have a few suggestions:
configure script: don't allow the --with-usb for non freebsd boxes.
makefiles: it continues even if it doesn't fully build the program.
(like when someone puts --with-usb on a linux system, it
doesn't find the usb.h file, and thus dies, but makefile
doesn't).
On linux, either make a (non-fatal) warning when '-t usb' is used,
or just ignore it (the prefered way).
"new_PConnection: unknown listen type 3" doesn't make sense (to me).
Strangly, that error only happens when I specify the device on the
command line. (I assume this is because it takes the type from the
listen directive in the coldsyncrc file.).
The ability to not display these "common" errors. (and please don't
suggest '2>/dev/null', because I want to see more serious errors).
The ability to have a "verbose" mode, which displays the files that
are currenlty being sync-ed. This way we can know where it is
at/status. Along with this would be cool to have a speed measurement
and or error count.
There was some mention in the docs that you could set the speed on
the comandline, but I couldn't figure out how to do that. Clarification
would be nice.
Sorry for spamming you all again!
Ryan
>
> Yeah, you're going to continue seeing "Bad CRC" errors under Linux
> until the serial device is fixed (or until you comment out that fprintf()
> :-) ). When it gets a malformed packet like that, ColdSync doesn't
> acknowledge it and waits for the Palm to resend it, just as it's always
> done.
> The improvement in v1.5.3 is that it no longer falls over with
> "Unexpected data packet. I'm confused!", which was the main reason why it
> would fail to complete a sync[1]. Now that it can deal with these cases,
> it stands a much better chance of completing a full sync, even on a noisy
> serial line.
>
> [1] In case you care: this happened when ColdSync sent out a data packet
> and waited for an ACK packet from the Palm. But instead of an ACK, it got
> another data packet.
> This can happen if the Palm sent ColdSync a data packet, and
> ColdSync acknowledged it, but the ACK got lost or corrupt on the way to
> the Palm. In this case, the Palm would resend the data packet again. But
> as far as ColdSync was concerned, it had already received the data packet
> and send back an ACK.
> In 1.5.3, ColdSync figures that whatever the data packet is, it's
> old news, and unimportant. So it sends back an ACK to shut the Palm up,
> and tries resending.
>
> --
> Andrew Arensburger Actually, these _do_ represent the
> arensb@ooblick.com opinions of ooblick.com!
> Generic Tagline V 6.01
>
>
> --
> This message was sent through the coldsync-hackers mailing list. To remove
> yourself from this mailing list, send a message to majordomo@thedotin.net
> with the words "unsubscribe coldsync-hackers" in the message body. For more
> information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.
>
--
Ryan VanderBijl http://www.calvin.edu/~rvbijl39
--
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.