 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This one might be interesting:
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/01/2014 03:52, clipka a écrit :
> This one might be interesting:
>
>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>
The link seems to be bad...
--
Do not judge my words, judge my actions.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/01/14 10:38, FractRacer wrote:
> Le 22/01/2014 03:52, clipka a écrit :
>> This one might be interesting:
>>
>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>>
>>
>
> The link seems to be bad...
The link's OK with me (from the UK)
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/01/2014 11:52, Doctor John a écrit :
> On 22/01/14 10:38, FractRacer wrote:
>> Le 22/01/2014 03O:52, clipka a écrit :
>>> This one might be interesting:
>>>
>>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>>>
>>>
>>
>> The link seems to be bad...
>
> The link's OK with me (from the UK)
>
> John
>
After some tries it's Ok.
Wonderful PC!
--
Do not judge my words, judge my actions.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/21/2014 7:52 PM, clipka wrote:
> This one might be interesting:
>
>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>
Hmm. Very similar to this:
http://www.kickstarter.com/projects/alexklein/kano-a-computer-anyone-can-make
Though, the latter case its a fully working PC which kids can "put
together" and learn how to program.
--
Commander Vimes: "You take a bunch of people who don't seem any
different from you and me, but when you add them all together you get
this sort of huge raving maniac with national borders and an anthem."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.01.2014 05:11, schrieb Patrick Elliott:
> On 1/21/2014 7:52 PM, clipka wrote:
>> This one might be interesting:
>>
>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>>
>>
> Hmm. Very similar to this:
>
> http://www.kickstarter.com/projects/alexklein/kano-a-computer-anyone-can-make
>
>
> Though, the latter case its a fully working PC which kids can "put
> together" and learn how to program.
Uh, no - not really. That's a Raspberry Pi with a tiny keyboard and
external speaker.
The Tango is a full-fledged x86-compatible PC (except that you need a
docking station to connect any external stuff to it).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
Interesting idea with the heat sink design, what would be better is to
have a screen and a "low power" mode so you could use it as a smartphone
without any docking station.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.01.2014 11:27, schrieb scott:
>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>>
>
> Interesting idea with the heat sink design, what would be better is to
> have a screen and a "low power" mode so you could use it as a smartphone
> without any docking station.
I thought so, too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28-1-2014 11:40, clipka wrote:
> Am 28.01.2014 11:27, schrieb scott:
>>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>>>
>>>
>>
>> Interesting idea with the heat sink design, what would be better is to
>> have a screen and a "low power" mode so you could use it as a smartphone
>> without any docking station.
>
> I thought so, too.
>
Why not an input on your mobile phone so you can use it as the display?
We already have a heap of remote controles, why add a heap of hand held
displays to that?
--
Everytime the IT department forbids something that a researcher deems
necessary for her work there will be another hole in the firewall.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Interesting idea with the heat sink design, what would be better is to
>> have a screen and a "low power" mode so you could use it as a smartphone
>> without any docking station.
>
> I thought so, too.
Although thinking about it a bit more, why exactly would you want to
take the same physical PC "core" around with you? With cloud-based
services and faster internet speeds nowadays is there really a big need
for this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 28 Jan 2014 12:27:42 +0200, scott <sco### [at] scott com> wrote:
>>
http://www.indiegogo.com/projects/tango-pc-worlds-most-powerful-pocketable-dockable-gameable-officeable-pc
>
> Interesting idea with the heat sink design, what would be better is to
> have a screen and a "low power" mode so you could use it as a smartphone
> without any docking station.
>
>
It would be nice if the docking station could also take an S4 or G2 and
change you phone into a PC :)
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-28 06:01, scott a écrit :
>>> Interesting idea with the heat sink design, what would be better is to
>>> have a screen and a "low power" mode so you could use it as a smartphone
>>> without any docking station.
>>
>> I thought so, too.
>
> Although thinking about it a bit more, why exactly would you want to
> take the same physical PC "core" around with you? With cloud-based
> services and faster internet speeds nowadays is there really a big need
> for this?
>
The dumb terminal connected to a powerful central computer vs.
distributed computing debate still rages on.
There are times when you need local processing oomphf, and even with
cloud-based services, the size of the planet has not changed. If you
save your files to "the cloud" from your home in europe, they'll
probably reside on a server in Europe. Stepping off the plane in
Singapour and trying to work on those files from the hotel will suck.
Tremendously.
One of our customers found this out the hard way a few years ago when
they tried to offshore part of their engineering dept to India, and
quickly realized that sharing gigabyte-sized CATIA files between
North-America and India, every day wouldn't work, simply due to the
network lag.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.01.2014 12:01, schrieb scott:
>>> Interesting idea with the heat sink design, what would be better is to
>>> have a screen and a "low power" mode so you could use it as a smartphone
>>> without any docking station.
>>
>> I thought so, too.
>
> Although thinking about it a bit more, why exactly would you want to
> take the same physical PC "core" around with you? With cloud-based
> services and faster internet speeds nowadays is there really a big need
> for this?
The cloud service that I'd trust to store my data still has to be invented.
It's going to be a difficult challenge though: The costs should be low
enough for me to afford it, but at the same high enough to give me
reassurance that the people know what they're doing and are using
reliable hardware, software, and contingency procedures.
There's also the problem that I'm making myself dependent on something
that I have to pay monthly for. I prefer to buy stuff for a fixed price
and then use it as long as I want / have to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There are times when you need local processing oomphf,
So have a standard PC at each location you work, rather than a docking
station and then physically carrying the CPU/GPU/RAM/HD between each
location. If you need to transfer a large amount of data in the time it
takes you to move between the two locations, then take a USB stick.
> and even with
> cloud-based services, the size of the planet has not changed. If you
> save your files to "the cloud" from your home in europe, they'll
> probably reside on a server in Europe. Stepping off the plane in
> Singapour and trying to work on those files from the hotel will suck.
> Tremendously.
If you're working in a hotel you're going to be carrying a laptop
anyway, so the device in the OP is not really any advantage. Besides,
unless every hotel had that exact brand and model of docking station,
you'd need to carry that too (and a screen).
> One of our customers found this out the hard way a few years ago when
> they tried to offshore part of their engineering dept to India, and
> quickly realized that sharing gigabyte-sized CATIA files between
> North-America and India, every day wouldn't work, simply due to the
> network lag.
You've done something wrong if you have a single gigabyte-sized CATIA
file. I expect what they had was a large assembly (consisting of a large
number of much smaller CATIA files) and were attempting to send the
entire set of files every day. I've worked somewhere before that did
that between UK and Japan, but the total assemblies were only <20MB so
it worked ok (apart from the version control problems...).
However, lots and lots companies work on much larger assemblies across
multiple sites (eg car and plane manufacturers), so this problem has
been solved already. Even CATIA itself (and various 3rd party software)
will allow you to only download the sub-assembly you are working on
(using simplified representations of large sub-assemblies if needed) and
then upload only the modified parts when you are done.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Although thinking about it a bit more, why exactly would you want to
>> take the same physical PC "core" around with you? With cloud-based
>> services and faster internet speeds nowadays is there really a big need
>> for this?
>
> The cloud service that I'd trust to store my data still has to be invented.
You can always encrypt it before uploading, and hold it on two separate
services in case one suddenly decides to disappear.
Anyway, if you want to transfer your data on your person (and trust
yourself not to lose it or get mugged) then why not just a USB stick?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-29 03:30, scott a écrit :
> You've done something wrong if you have a single gigabyte-sized CATIA
> file. I expect what they had was a large assembly (consisting of a large
> number of much smaller CATIA files) and were attempting to send the
> entire set of files every day. I've worked somewhere before that did
> that between UK and Japan, but the total assemblies were only <20MB so
> it worked ok (apart from the version control problems...).
Ok fine, I should have written "gygabytes of CATIA files". It's been
20 years since I played with CATIA, so my knowledge of the file
structure is somewhat shady.
The design of this setup had the Indians accessing the files (on servers
that were in Canada), verifiy that they conformed to various standards,
flag non-conformities for review, and then move to the next file.
A 20MB file is 16M bits. At 1500bits per packet, it means ~ 110,000
packets. If the round trip takes 200-400ms per packet, then it takes
20,000 seconds, or more than 6 hrs, ignoring link congestion and other
technicalities, for someone to open the file from India.
Which meant that an Indian could only review 2, or maybe 3 files per
day, making this outsourcing deal completely worthless as the
productivity of an Indian worker paid $15/day was worse than that of a
Canadian intern paid $15/hr.
that why I said that "The Cloud" may help one manager work on his
monthly report while on the train back home in the evening, and
technically allows you to access your files from anywhere, but it
doesn't solve everyone's problem.
>
> However, lots and lots companies work on much larger assemblies across
> multiple sites (eg car and plane manufacturers), so this problem has
> been solved already.
I know that. For instance, the suspension components of the Ferrari F1
cars is (used to be?) designed in my building in Montreal, and they had
no issues with being on a different continent than the rest of the
Scuderia staff.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.01.2014 15:26, schrieb Francois Labreque:
> A 20MB file is 16M bits. At 1500bits per packet, it means ~ 110,000
> packets. If the round trip takes 200-400ms per packet, then it takes
> 20,000 seconds, or more than 6 hrs, ignoring link congestion and other
> technicalities, for someone to open the file from India.
That's why any sane file transfer protocol sends more than just one
packet before waiting for an acknowledge.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> A 20MB file is 16M bits. At 1500bits per packet, it means ~ 110,000
> packets. If the round trip takes 200-400ms per packet, then it takes
> 20,000 seconds, or more than 6 hrs, ignoring link congestion and other
> technicalities, for someone to open the file from India.
That's one sloooooow connection - luckily nowadays "the cloud" is a lot
faster, IME companies specialising in that type of engineering
outsourcing work usually have very fast connections (they would have
received a 20MB file before you could call them and say "hello").
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-29 09:49, clipka a écrit :
> Am 29.01.2014 15:26, schrieb Francois Labreque:
>
>> A 20MB file is 16M bits. At 1500bits per packet, it means ~ 110,000
>> packets. If the round trip takes 200-400ms per packet, then it takes
>> 20,000 seconds, or more than 6 hrs, ignoring link congestion and other
>> technicalities, for someone to open the file from India.
>
> That's why any sane file transfer protocol sends more than just one
> packet before waiting for an acknowledge.
>
Yes, and even accounting for that, with the TCP window size of 16k of
the AIX servers in question, you have to receive an ACK every 12-13
packets or you run the risk of exceeding your window size and having the
source start retransmitting.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-29 09:52, scott a écrit :
>> A 20MB file is 16M bits. At 1500bits per packet, it means ~ 110,000
>> packets. If the round trip takes 200-400ms per packet, then it takes
>> 20,000 seconds, or more than 6 hrs, ignoring link congestion and other
>> technicalities, for someone to open the file from India.
>
> That's one sloooooow connection - luckily nowadays "the cloud" is a lot
> faster, IME companies specialising in that type of engineering
> outsourcing work usually have very fast connections (they would have
> received a 20MB file before you could call them and say "hello").
200ms from North America to India is extremely fast.
See for example, tracerouting from my home PC to the Indian govt web site.
C:\Documents and Settings\Francois>tracert india.gov.in
Tracing route to india.gov.in [164.100.129.97]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 8 ms 10 ms 17 ms 10.21.136.1
3 16 ms 12 ms 10 ms 216.113.124.170
4 22 ms 27 ms 23 ms 216.113.123.249
5 20 ms 21 ms 32 ms eqix-ny9.bhartiairtel.com [198.32.118.170]
6 292 ms 295 ms 295 ms 182.79.255.249
7 302 ms 295 ms 293 ms
ABTS-North-Static-218.176.144.59.airtelbroadband
.in [59.144.176.218]
8 * * * Request timed out.
9 * * * Request timed out.
10 * ^C
C:\Documents and Settings\Francois>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/01/14 01:43, Francois Labreque wrote:
>
> See for example, tracerouting from my home PC to the Indian govt web site.
>
> C:\Documents and Settings\Francois>tracert india.gov.in
>
> Tracing route to india.gov.in [164.100.129.97]
> over a maximum of 30 hops:
>
> 1 <1 ms <1 ms <1 ms 192.168.1.1
> 2 8 ms 10 ms 17 ms 10.21.136.1
> 3 16 ms 12 ms 10 ms 216.113.124.170
> 4 22 ms 27 ms 23 ms 216.113.123.249
> 5 20 ms 21 ms 32 ms eqix-ny9.bhartiairtel.com [198.32.118.170]
> 6 292 ms 295 ms 295 ms 182.79.255.249
> 7 302 ms 295 ms 293 ms
> ABTS-North-Static-218.176.144.59.airtelbroadband
> ..in [59.144.176.218]
> 8 * * * Request timed out.
> 9 * * * Request timed out.
> 10 * ^C
> C:\Documents and Settings\Francois>
>
An interesting experiment. From my machine (UK based) I get:
aphrodite:/home/john # traceroute -m 50 india.gov.in
traceroute to india.gov.in (164.100.129.97), 50 hops max, 60 byte packets
1 BThomehub.home (192.168.1.254) 2.084 ms 2.978 ms 3.046 ms
2 217.32.146.161 (217.32.146.161) 22.737 ms 24.163 ms 24.778 ms
3 217.32.146.190 (217.32.146.190) 26.508 ms 26.588 ms 27.874 ms
4 217.32.147.218 (217.32.147.218) 29.319 ms 29.922 ms 30.652 ms
5 213.120.178.69 (213.120.178.69) 32.326 ms 35.687 ms 36.942 ms
6 217.41.168.109 (217.41.168.109) 37.880 ms 22.664 ms 23.369 ms
7 109.159.249.236 (109.159.249.236) 24.668 ms 109.159.249.238
(109.159.249.238) 22.990 ms acc2-10GigE-0-2-0-7.l-far.21cn-ipp.bt.net
(109.159.249.231) 24.066 ms
8 core1-te0-7-0-17.faraday.ukcore.bt.net (109.159.249.141) 27.245 ms
core1-te0-7-0-15.faraday.ukcore.bt.net (109.159.249.165) 27.899 ms
core2-te0-15-0-6.faraday.ukcore.bt.net (109.159.249.161) 31.393 ms
9 peer2-xe8-0-1.telehouse.ukcore.bt.net (109.159.254.179) 27.944 ms
host213-121-193-131.ukcore.bt.net (213.121.193.131) 28.547 ms 29.640 ms
10 166-49-211-184.eu.bt.net (166.49.211.184) 30.404 ms
t2c3-xe-0-1-3-0.uk-lon1.eu.bt.net (166.49.211.168) 31.310 ms
166-49-211-196.eu.bt.net (166.49.211.196) 22.549 ms
11 linx1.teleglobe.net (195.66.224.51) 50.413 ms 50.465 ms 50.788 ms
12 if-26-2.tcore2.LDN-London.as6453.net (80.231.62.57) 56.706 ms
57.295 ms 53.750 ms
13 if-15-2.tcore2.L78-London.as6453.net (80.231.131.117) 52.537 ms *
53.601 ms
14 if-9-2.tcore2.WYN-Marseille.as6453.net (80.231.200.13) 54.922 ms
56.086 ms 56.757 ms
15 * 80.231.200.26 (80.231.200.26) 154.565 ms 155.180 ms
16 * * *
17 14.140.113.30.static-Delhi-vsnl.net.in (14.140.113.30) 174.327 ms
176.294 ms 175.233 ms
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But to Japan I get:
aphrodite:/home/john # traceroute -m 50 www.mofa.go.jp
traceroute to www.mofa.go.jp (213.123.84.48), 50 hops max, 60 byte packets
1 BThomehub.home (192.168.1.254) 1.686 ms 2.504 ms 2.648 ms
2 217.32.146.161 (217.32.146.161) 23.864 ms 24.527 ms 25.340 ms
3 217.32.146.206 (217.32.146.206) 26.355 ms 28.282 ms 28.443 ms
4 217.32.147.226 (217.32.147.226) 30.669 ms 30.921 ms 31.532 ms
5 213.120.178.69 (213.120.178.69) 32.794 ms 34.308 ms 34.983 ms
6 217.41.168.109 (217.41.168.109) 36.644 ms 22.228 ms 22.540 ms
7 31.55.162.69 (31.55.162.69) 23.263 ms 24.171 ms 25.002 ms
8 213.123.84.48 (213.123.84.48) 25.734 ms 26.117 ms 27.255 ms
I think this says more about Indian infrastructure than anything else.
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> That's one sloooooow connection - luckily nowadays "the cloud" is a lot
>> faster, IME companies specialising in that type of engineering
>> outsourcing work usually have very fast connections (they would have
>> received a 20MB file before you could call them and say "hello").
>
> 200ms from North America to India is extremely fast.
I'm talking about your transfer rate of 20MB in 6 hours being slow. I
have a 143 ms ping here to www.microsoft.com but can download at over a
megabyte per second. How are the two linked? If your link took 6 hours
to download 20MB then it wasn't because of the ping being 200ms.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-29 21:06, Doctor John a écrit :
> But to Japan I get:
>
> aphrodite:/home/john # traceroute -m 50 www.mofa.go.jp
> traceroute to www.mofa.go.jp (213.123.84.48), 50 hops max, 60 byte packets
> 1 BThomehub.home (192.168.1.254) 1.686 ms 2.504 ms 2.648 ms
> 2 217.32.146.161 (217.32.146.161) 23.864 ms 24.527 ms 25.340 ms
> 3 217.32.146.206 (217.32.146.206) 26.355 ms 28.282 ms 28.443 ms
> 4 217.32.147.226 (217.32.147.226) 30.669 ms 30.921 ms 31.532 ms
> 5 213.120.178.69 (213.120.178.69) 32.794 ms 34.308 ms 34.983 ms
> 6 217.41.168.109 (217.41.168.109) 36.644 ms 22.228 ms 22.540 ms
> 7 31.55.162.69 (31.55.162.69) 23.263 ms 24.171 ms 25.002 ms
> 8 213.123.84.48 (213.123.84.48) 25.734 ms 26.117 ms 27.255 ms
>
> I think this says more about Indian infrastructure than anything else.
>
> John
>
I think your ISP is playing tricks on you. At least mine is being
honest about it...
C:\Documents and Settings\Francois>tracert www.mofa.go.jp
Tracing route to a122.dscksd.akamai.net [24.200.239.194]
over a maximum of 30 hops:
1 <1 ms <1 ms 15 ms 192.168.1.1
2 8 ms 9 ms 8 ms 10.21.136.1
3 10 ms 12 ms 15 ms 216.113.124.157
4 10 ms 10 ms 9 ms cache.google.com [24.200.239.194]
Trace complete.
C:\Documents and Settings\Francois>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-30 03:22, scott a écrit :
>>> That's one sloooooow connection - luckily nowadays "the cloud" is a lot
>>> faster, IME companies specialising in that type of engineering
>>> outsourcing work usually have very fast connections (they would have
>>> received a 20MB file before you could call them and say "hello").
>>
>> 200ms from North America to India is extremely fast.
>
> I'm talking about your transfer rate of 20MB in 6 hours being slow. I
> have a 143 ms ping here to www.microsoft.com but can download at over a
> megabyte per second. How are the two linked? If your link took 6 hours
> to download 20MB then it wasn't because of the ping being 200ms.
I suspect that Microsoft will have servers in the UK to send files to
faster than if you were getting them from Redmond.
Secondly, I never claimed that the network latency was the only reason
for the length of the transfer, but it is definitely one of the main
reasons.
This is how it goes (let's assume a well behaved protocol, like FTP):
Every ten packets or so, the sender has to wait for the recipient to
acknoledge reception of the packets,
Server sends 10 packets...
... it takes 200ms for them to get there.
Client acknowledges...
... it takes 200ms for the acknowlegdement to get back.
Server send 10 more packets...
etc...
Now, as Dr. John said in another e-mail, we have to take into account
the quality of the Indian telecommunications infrastructure, so let's
say that 1 packet out of 20 gets dropped, sometimes the scenario becomes:
Server sends 10 packets...
... it takes 200ms for them to get there, but packet #4 got dropped.
Client acknowledges reception of the first 3... packets 5-10 are ignored.
... it takes 200ms for the acknowlegdement to get back.
Server re-sends packets 4-10 and sends 11-13...
etc...
Now, remember that there are supposed to be multiple persons in India
trying to load different files at the same time, so on top of the
retransmissions due to poor line quality, you also run the risk of
having congestions, causing delays in transmission, which will make the
server assume that none of the packets were received, since they weren't
acknoleged on time, causing them to be resent, causing further congestion.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Server sends 10 packets...
> ... it takes 200ms for them to get there, but packet #4 got dropped.
> Client acknowledges reception of the first 3... packets 5-10 are ignored.
> ... it takes 200ms for the acknowlegdement to get back.
> Server re-sends packets 4-10 and sends 11-13...
> etc...
LOL if anyone wrote a protocol to work like that they should be shot!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-31 02:59, scott a écrit :
>> Server sends 10 packets...
>> ... it takes 200ms for them to get there, but packet #4 got dropped.
>> Client acknowledges reception of the first 3... packets 5-10 are ignored.
>> ... it takes 200ms for the acknowlegdement to get back.
>> Server re-sends packets 4-10 and sends 11-13...
>> etc...
>
> LOL if anyone wrote a protocol to work like that they should be shot!
>
You mean like this?
http://www.rfc-editor.org/rfc/rfc793.txt
http://www.rfc-editor.org/rfc/rfc813.txt
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-31 09:27, Francois Labreque a écrit :
> Le 2014-01-31 02:59, scott a écrit :
>>> Server sends 10 packets...
>>> ... it takes 200ms for them to get there, but packet #4 got dropped.
>>> Client acknowledges reception of the first 3... packets 5-10 are
>>> ignored.
>>> ... it takes 200ms for the acknowlegdement to get back.
>>> Server re-sends packets 4-10 and sends 11-13...
>>> etc...
>>
>> LOL if anyone wrote a protocol to work like that they should be shot!
>>
> You mean like this?
>
> http://www.rfc-editor.org/rfc/rfc793.txt
> http://www.rfc-editor.org/rfc/rfc813.txt
>
>
Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
- is already dead, so you can't shoot him.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You mean like this?
>>
>> http://www.rfc-editor.org/rfc/rfc793.txt
>> http://www.rfc-editor.org/rfc/rfc813.txt
I guess back then we didn't imagine it would be completely normal to
transfer gigabytes of data around the world at hundreds of megabits per
second.
> Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
> - is already dead, so you can't shoot him.
Good job RFC-2018 was written then to fix the exact problem you highlighted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-31 10:12, scott a écrit :
>>> You mean like this?
>>>
>>> http://www.rfc-editor.org/rfc/rfc793.txt
>>> http://www.rfc-editor.org/rfc/rfc813.txt
>
> I guess back then we didn't imagine it would be completely normal to
> transfer gigabytes of data around the world at hundreds of megabits per
> second.
>
>> Forgot to add: Johnathan Postel - who wrote most of the early IETF RFCs
>> - is already dead, so you can't shoot him.
>
> Good job RFC-2018 was written then to fix the exact problem you
> highlighted.
>
And Cisco load balancers clear those options, by default. (And guess
what kinds of problems I've been troubleshooting for the last few months?)
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/security/guide/tcpipnrm.html#wp1010795
I guess that's one reason why they're running out of that business!
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
