 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
