No, need to get your panties in a bunch, I was just making a point.... I am sure, if you wanted to, you could use a packet to transmit a single bit.
I didn't think through the math, because the latency in theory could be iinfinite.... So, yes, it's concievable that a 56k modem is faster if it has no latency, no matter what kind of assumptions you make. Once again, I was just trying to illustrate that you can bring the fastest system to its knees by doing stupid things. On Jan 17, 1:52 pm, Jim Graham <spooky1...@gmail.com> wrote: > On Mon, Jan 16, 2012 at 08:15:50PM -0800, Zsolt Vasvari wrote: > > Or let's take a networking example (since the communactions between a > > CPU and the GPU is a network) > > Which one is faster? > > Sending a 1MB file in ONE CHUNK over a 56kbps dial-up line or sending > > the same file, ONE BIT AT A TIME, using TCP/IP over high speed > > internet? My guess is the former... > > Ummm, where do you get this (mistaken) idea that IP only transmits > one bit (or even one byte) at a time? Please post your reference > (specifically, the RFC that makes this claim). > > Second, a 56 kb/s dial-up modem, even with the speed increase gained by > adding error control[1], you're still getting far, FAR less throughput > than even a relatively slow HSI link (or even a much-slower DSL link, at > around 512 kb/s...or is that 512 kB/s? sorry, I don't do DSL...too > fscking slow compared to the HSI option here, where I get up to 4 MB/s, > limited by my laptop, not the network bandwidth). > > And with a dial-up modem, you are most definitely NOT sending a 1 MB file > in a single chunk. You are sending a lot of much smaller packets (the > size of which depends on exactly which file transfer protocol you are > referring to), but you are definitely not sending it in one big chunk. > But then, with TCP/IP, you also are not sending one fscking bit at a > time, either. > > Want the math? See [1] below. > > Later, > --jim > > [1] No, that was not a joke. Adding error control, whether it's CCITT > (now ITU-T) V.42 or MNP3/4 does in fact, with a relatively error-free > line, ADD throughput. Adding error control changes the number of > bits/character from 10 to 8 by stripping start/stop bits as part of > its async-to-sync conversion. Here's the math: > > For V.32bis (14.4 kb/s)...you can use the same math for higher > dial-up speeds to calculate the end-to-end throughput: > > Without error control: > T(max) == (14400 bps / 10 bits/char) == 1440 cps maximum > > With error control (V.42/LAPM or MNP3/4): > > T(max) = (14400 bps / 8 bits/char) * 128/135 * 62/63 == 1679.58 cps > > where: 128/135 is the FCS + framing overhead > 62/63 is the bit stuffing overhead (typical average 1 bit > stuffed for every 62 bits of data) > > -- > THE SCORE: ME: 2 CANCER: 0 > 73 DE N5IAL (/4) | "This 'telephone' has too many > spooky1...@gmail.com | shortcomings to be seriously considered > < Running FreeBSD 7.0 > | as a means of communication. The device > ICBM / Hurricane: | is inherently of no value to us." > 30.44406N 86.59909W | (Western Union internal memo, 1876) > > Android Apps Listing athttp://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
