Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.advocacy > #350942 > unrolled thread

The Inevitable Death of the Windows PC

Back to article view | Back to comp.os.linux.advocacy

Contents

  The Inevitable Death of the Windows PC Homer <usenet@slated.org> - 2016-04-20 11:06 +0100
    Re: I don't have to hold no fucking phone. Homer <usenet@slated.org> - 2016-04-20 11:57 +0100
      Re: I don't have to hold no fucking phone. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-20 13:49 +0200
        Re: I don't have to hold no fucking phone. DFS <nospam@dfs.com> - 2016-04-20 10:07 -0400
          Re: I don't have to hold no fucking phone. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-20 19:12 +0200
            Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor. Jeff-Relf.Me <@.> - 2016-04-20 11:57 -0700
              Re: Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-20 23:42 +0200
                Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III limited. Jeff-Relf.Me <@.> - 2016-04-20 14:55 -0700
                  Re: Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III limited. Melzzzzz <mel@zzzzz.com> - 2016-04-21 00:04 +0200
                    Why does it take less than 3 seconds to make the second copy of the 4 gig file ? Jeff-Relf.Me <@.> - 2016-04-20 17:08 -0700
                      Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ? Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-21 09:00 +0200
                        Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ? moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-04-21 17:00 +0000
                          Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ? Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-21 19:05 +0200
              Re: Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor. Incubus <incubus9536612@gmail.com> - 2016-04-22 06:07 -0700
            Re: I don't have to hold no fucking phone. DFS <nospam@dfs.com> - 2016-04-22 10:09 -0400
              The first copy ( of a 4 gig file ) takes 11 seconds. Jeff-Relf.Me <@.> - 2016-04-22 11:55 -0700
                Re: The first copy ( of a 4 gig file ) takes 11 seconds. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-22 23:27 +0200
                  Re: The first copy ( of a 4 gig file ) takes 11 seconds. Richard King <kingsley651@webby.org> - 2016-04-22 17:55 -0400
                    Re: The first copy ( of a 4 gig file ) takes 11 seconds. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-23 00:05 +0200
                      Re: The first copy ( of a 4 gig file ) takes 11 seconds. Richard King <kingsley651@webby.org> - 2016-04-22 18:20 -0400
                        Re: The first copy ( of a 4 gig file ) takes 11 seconds. Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-23 01:01 +0200
                          Re: The first copy ( of a 4 gig file ) takes 11 seconds. Richard King <kingsley651@webby.org> - 2016-04-22 19:11 -0400
      Re: I don't have to hold no fucking phone. chrisv <chrisv@nospam.invalid> - 2016-04-20 07:05 -0500
        Re: I don't have to hold no fucking phone. Sandman <mr@sandman.net> - 2016-04-20 12:28 +0000
      Re: The subjective preferences of the dying minority Homer <usenet@slated.org> - 2016-04-20 13:58 +0100
    Re: The Inevitable Death of the Windows PC DFS <nospam@dfs.com> - 2016-04-20 10:18 -0400
    Re: The Inevitable Death of the Windows PC ronb <ronb02NOSPAM@gmail.com> - 2016-04-20 17:09 +0000
      Re: The Inevitable Death of the Windows PC Me Sham <osirus47@yahoo.com> - 2016-04-20 10:38 -0700
        Re: The Inevitable Death of the Windows PC Desk Rabbit <me@example.com> - 2016-04-22 12:11 +0100
    Re: The Inevitable Death of the Windows PC 7 <7@enemygadgets.com> - 2016-04-20 20:51 +0000
    Re: The Inevitable Death of the Windows PC JEDIDIAH <jedi@nomad.mishnet> - 2016-04-20 15:53 -0500
      Re: The Inevitable Death of the Windows PC 7 <7@enemygadgets.com> - 2016-04-20 22:01 +0000
        Re: The Inevitable Death of the Windows PC Desk Rabbit <me@example.com> - 2016-04-22 12:14 +0100
          Re: The Inevitable Death of the Windows PC GreyCloud <mist@cumulus.com> - 2016-04-22 16:37 -0600

Page 1 of 2  [1] 2  Next page →

#350942 — The Inevitable Death of the Windows PC

Here are three stories that confirm and explain the death of the Windows PC.

1. Peak Cable looms: One in five US homes now mobile-only for internet

'Those numbers back up the contention that more and more Americans are
opting to cut the cord with their home connections and dump cable or DSL
providers in favor of mobile plans. They also fall in line with the
saturation of handsets and tablets, while desktop PCs and notebooks
suffer plummeting sales.

"Americans’ rapid move toward mobile Internet service appears to be
coming at the expense of home broadband connections," wrote Giulia
McHenry, chief economist for the NTIA's office of policy analysis and
development.

"At the same time, many Americans are using a wider range of computing
devices in their daily lives."'

http://www.theregister.co.uk/2016/04/19/one_in_five_us_homes_now_mobileonly

2. Hey Windows 10, weren't you supposed to help PC sales?

'Very few if any ever thought Windows 10 would truly reinvigorate the PC
industry, and they were right - IDC has pulled down forecasts on
traditional device sales for 2016.

The analyst has clipped unit expectations by a couple of per cent,
claiming global notebooks and desktops shipments into channels are now
on course to decline 5.4 per cent to 260.9 million.

That’ll equate to 156.2 million portable PCs and 104.7 million
desk-based units for the year if the beanies are right, but these things
tend to be a moving feast and further corrections are likely.

In the medium term, things aren’t going to get markedly better either -
over the next five years compound annual growth rates of minus 0.5 per
cent are predicted.

The operating system can’t shoulder sole responsibility for unit sales
to date or the crappy outlook but it has played a part, and was fingered
by HP Inc last summer and again more recently.'

http://www.theregister.co.uk/2016/03/14/pc_sales_forecasts

3. Intel literally decimates workforce: 12,000 will be axed, CFO shifts
to sales

'Intel will axe 12,000 employees globally – more than one in ten of its
workforce – as it moves further away from being a PC chip company.
The layoffs are among the biggest into the company's history, and come
as PC industry continues to tank harder than Intel expected.

The Santa Clara-based biz sees a lot of growth in the worlds of data
centers, memory, and the internet of things – anything that doesn't look
like a traditional desktop computer, the sales of which are dwindling.
As a result, fewer processors for normal PCs, laptops and tablets are
needed, and so Intel is rejigging itself to focus more on these growth
areas – which will mean losing some workers.'

http://www.theregister.co.uk/2016/04/19/intel_q1_fy2016_job_cuts

-- 
K.
http://slated.org

[toc] | [next] | [standalone]

#350950 — Re: I don't have to hold no fucking phone.

On Wednesday 20/04/2016 11:33 AM, Jeff-Relf.Me wrote:
>
> It takes 3.5 seconds to copy a 3.5 gig file.

That's great, but the vast majority of the market simply doesn't care.

You are part of a dying minority.

-- 
K.
http://slated.org

[toc] | [prev] | [next] | [standalone]

#350952 — Re: I don't have to hold no fucking phone.

Homer wrote:

> On Wednesday 20/04/2016 11:33 AM, Jeff-Relf.Me wrote:
>>
>> It takes 3.5 seconds to copy a 3.5 gig file.
> 
> That's great, but the vast majority of the market simply doesn't care.
> 
> You are part of a dying minority.
> 

It is also balderdash.

The drive he is talking about manages 540 MB/sec on reads.
For his claim to be true he needs 1000 MB/sec read *and* write

That Relf-Cretin is like all the other wintendo lusers in COLA. A lying 
twit, dumb beyond imagination. Unable even to make up a claim which can't be 
disproven by extremely simple to get facts. He is just like the other 
widiots in here: A typical Snit. Dishonest to the bone

[toc] | [prev] | [next] | [standalone]

#350975 — Re: I don't have to hold no fucking phone.

On 4/20/2016 7:49 AM, Peter Köhlmann wrote:
> Homer wrote:
>
>> On Wednesday 20/04/2016 11:33 AM, Jeff-Relf.Me wrote:
>>>
>>> It takes 3.5 seconds to copy a 3.5 gig file.
>>
>> That's great, but the vast majority of the market simply doesn't care.
>>
>> You are part of a dying minority.
>>
>
> It is also balderdash.
>
> The drive he is talking about manages 540 MB/sec on reads.
> For his claim to be true he needs 1000 MB/sec read *and* write
>
> That Relf-Cretin is like all the other wintendo lusers in COLA. A lying
> twit, dumb beyond imagination. Unable even to make up a claim which can't be
> disproven by extremely simple to get facts. He is just like the other
> widiots in here: A typical Snit. Dishonest to the bone


3.5 secs sounds reasonable, if this is his drive.

http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html

Performance**	Sequential Read	Max. 550 MB/s
Sequential Write**
Max. 520 MB/s (256 GB/512 GB/1 TB/2 TB)
Max. 470 MB/s (128 GB)
4KB Random Read (QD1)	Max. 10,000 IOPS
4KB Random Write (QD1)	Max. 36,000 IOPS
4KB Random Read (QD32)	Max. 100,000 IOPS
4KB Random Write (QD32)	Max. 90,000 IOPS

[toc] | [prev] | [next] | [standalone]

#351016 — Re: I don't have to hold no fucking phone.

DFS wrote:

> On 4/20/2016 7:49 AM, Peter Köhlmann wrote:
>> Homer wrote:
>>
>>> On Wednesday 20/04/2016 11:33 AM, Jeff-Relf.Me wrote:
>>>>
>>>> It takes 3.5 seconds to copy a 3.5 gig file.
>>>
>>> That's great, but the vast majority of the market simply doesn't care.
>>>
>>> You are part of a dying minority.
>>>
>>
>> It is also balderdash.
>>
>> The drive he is talking about manages 540 MB/sec on reads.
>> For his claim to be true he needs 1000 MB/sec read *and* write
>>
>> That Relf-Cretin is like all the other wintendo lusers in COLA. A lying
>> twit, dumb beyond imagination. Unable even to make up a claim which can't
>> be disproven by extremely simple to get facts. He is just like the other
>> widiots in here: A typical Snit. Dishonest to the bone
> 
> 
> 3.5 secs sounds reasonable, if this is his drive.
> 
> 
http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html
> 
> Performance**	Sequential Read	Max. 550 MB/s
> Sequential Write**
> Max. 520 MB/s (256 GB/512 GB/1 TB/2 TB)
> Max. 470 MB/s (128 GB)

So how do you propose being able to copy 3.5 GB in 3.5 seconds when the 
drive needs 7 seconds just to read the data? Much less write it again.

Your poor math capabilities show their ugly head again. Face it, you can't 
add even simple numbers. With complex stuff you are completely lost

[toc] | [prev] | [next] | [standalone]

#351039 — Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

Replying to MrDFS (and me), Peter Köhlmann asks:
> > > > My $293 SSD drive:  Samsung 850 EVO, 1 TeraByte, superHigh IOPS
> > > >                       It takes 3.5 seconds to copy a 3.5 gig file.
> > 
> > 3.5 secs sounds reasonable, if this is his drive.
> > http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html
> > Sequential Read Max. 550 MB/s 
> > Sequential Write** Max. 520 MB/s
> 
> So how do you propose being able to copy 3.5 GB in 3.5 seconds when the 
> drive needs 7 seconds just to read the data? Much less write it again.

Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

[toc] | [prev] | [next] | [standalone]

#351064 — Re: Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

 wrote:

> Replying to MrDFS (and me), Peter Köhlmann asks:
>> > > > My $293 SSD drive:  Samsung 850 EVO, 1 TeraByte, superHigh IOPS
>> > > >                       It takes 3.5 seconds to copy a 3.5 gig file.
>> > 
>> > 3.5 secs sounds reasonable, if this is his drive.
>> > 
http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html
>> > Sequential Read Max. 550 MB/s
>> > Sequential Write** Max. 520 MB/s
>> 
>> So how do you propose being able to copy 3.5 GB in 3.5 seconds when the
>> drive needs 7 seconds just to read the data? Much less write it again.
> 
> Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

Idiot. The drive is. And can't read data at the rate you would need to copy 
in 3.5 seconds

You are dumber than DumbFullSnit, and it really shows

Well, your "programs" (what you are calling those abominations) show it too 
that you are way dumber than a demented brick

[toc] | [prev] | [next] | [standalone]

#351069 — Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III limited.

Peter Köhlmann,   "Your" benchmarks are SATA III limited.

Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III limited.

[toc] | [prev] | [next] | [standalone]

#351074 — Re: Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III limited.

On Wed, 20 Apr 2016 14:55:49 -0700 (Seattle)
Jeff-Relf.Me <@.> wrote:

> Peter Köhlmann,   "Your" benchmarks are SATA III limited.
> 
> Copying a 3.5 gig file from/to the Samsung 850 EVO isn't SATA III
> limited.

How so? Is your drive pci based? Copying data to write back buffer then
doing writes in background is what you probably experience...

[toc] | [prev] | [next] | [standalone]

#351091 — Why does it take less than 3 seconds to make the second copy of the 4 gig file ?

After a ReBoot, it takes 11 seconds to copy a 4 gig file
to/from my TeraByte Samsung 850 EVO; after that,
it takes _less_ than 3 seconds to copy it again.   Why ?

[toc] | [prev] | [next] | [standalone]

#351115 — Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ?

 wrote:

> After a ReBoot, it takes 11 seconds to copy a 4 gig file
> to/from my TeraByte Samsung 850 EVO; after that,
> it takes _less_ than 3 seconds to copy it again.   Why ?

Because it is buffered in your memory, you clueless dimbulb.
And no, it does *not* take just 3 seconds. You will need 7 seconds for the 
operation to finish, even though the OS might tell you earlier that its done 
(because of buffering). You simply can't bypass the physical limitations, 
and those are around 500 MB/sec. In other words: The operation will take 7 
seconds, not 3, you idiot

You make your widiot clowns proud again by not knowing even basic stuff

[toc] | [prev] | [next] | [standalone]

#351159 — Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ?

Peter =?UTF-8?B?S8O2aGxtYW5u?= <peter-koehlmann@t-online.de> writes:

> wrote:

>> After a ReBoot, it takes 11 seconds to copy a 4 gig file
>> to/from my TeraByte Samsung 850 EVO; after that,
>> it takes _less_ than 3 seconds to copy it again.   Why ?

>Because it is buffered in your memory, you clueless dimbulb.
>And no, it does *not* take just 3 seconds. You will need 7 seconds for the 
>operation to finish, even though the OS might tell you earlier that its done 
>(because of buffering). You simply can't bypass the physical limitations, 
>and those are around 500 MB/sec. In other words: The operation will take 7 
>seconds, not 3, you idiot

The difference between "write back caching" and "write through caching".
On a write, a disklike device (actual hard drive, RAID controller, Flash)
with cache can tell the OS "success" upon a write as soon as it gets the
data into its cache, or it can wait until the data is all safely onto
non-volatile media before returning success to the OS.  The first is much
faster than the second, but the second is much safer, in case something
goes wrong (such as a power failure at the wrong time in a poorly designed
system).

[toc] | [prev] | [next] | [standalone]

#351160 — Re: Why does it take less than 3 seconds to make the second copy of the 4 gig file ?

Michael Moroney wrote:

> Peter =?UTF-8?B?S8O2aGxtYW5u?= <peter-koehlmann@t-online.de> writes:
> 
>> wrote:
> 
>>> After a ReBoot, it takes 11 seconds to copy a 4 gig file
>>> to/from my TeraByte Samsung 850 EVO; after that,
>>> it takes _less_ than 3 seconds to copy it again.   Why ?
> 
>>Because it is buffered in your memory, you clueless dimbulb.
>>And no, it does *not* take just 3 seconds. You will need 7 seconds for the
>>operation to finish, even though the OS might tell you earlier that its
>>done (because of buffering). You simply can't bypass the physical
>>limitations, and those are around 500 MB/sec. In other words: The
>>operation will take 7 seconds, not 3, you idiot
> 
> The difference between "write back caching" and "write through caching".
> On a write, a disklike device (actual hard drive, RAID controller, Flash)
> with cache can tell the OS "success" upon a write as soon as it gets the
> data into its cache, or it can wait until the data is all safely onto
> non-volatile media before returning success to the OS.  The first is much
> faster than the second, but the second is much safer, in case something
> goes wrong (such as a power failure at the wrong time in a poorly designed
> system)

Not only just that. That cretinous dimbulb "Relf" (a very typical wintendo 
luser, dumb beyond any imagination) "tests" his drive with *one* copy of a 
large file. If he repeats that with a copy of several large files at once, 
he will see how long it really takes, because then the buffering will not 
work any more like it does with just one file

[toc] | [prev] | [next] | [standalone]

#351250 — Re: Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

On Wednesday, April 20, 2016 at 6:57:53 PM UTC, Jeff-Relf.Me wrote:
> Replying to MrDFS (and me), Peter Köhlmann asks:
> > > > > My $293 SSD drive:  Samsung 850 EVO, 1 TeraByte, superHigh IOPS
> > > > >                       It takes 3.5 seconds to copy a 3.5 gig file.
> > > 
> > > 3.5 secs sounds reasonable, if this is his drive.
> > > http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html
> > > Sequential Read Max. 550 MB/s 
> > > Sequential Write** Max. 520 MB/s
> > 
> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when the 
> > drive needs 7 seconds just to read the data? Much less write it again.
> 
> Copying a 3.5 gig file, locally, SATA III is not a (limiting) factor.

A decent filesystem doesn't perform a copy at all with a 'local' copy...

[toc] | [prev] | [next] | [standalone]

#351258 — Re: I don't have to hold no fucking phone.

On 4/20/2016 1:12 PM, Peter Köhlmann wrote:
> DFS wrote:
>
>> On 4/20/2016 7:49 AM, Peter Köhlmann wrote:
>>> Homer wrote:
>>>
>>>> On Wednesday 20/04/2016 11:33 AM, Jeff-Relf.Me wrote:
>>>>>
>>>>> It takes 3.5 seconds to copy a 3.5 gig file.
>>>>
>>>> That's great, but the vast majority of the market simply doesn't care.
>>>>
>>>> You are part of a dying minority.
>>>>
>>>
>>> It is also balderdash.
>>>
>>> The drive he is talking about manages 540 MB/sec on reads.
>>> For his claim to be true he needs 1000 MB/sec read *and* write
>>>
>>> That Relf-Cretin is like all the other wintendo lusers in COLA. A lying
>>> twit, dumb beyond imagination. Unable even to make up a claim which can't
>>> be disproven by extremely simple to get facts. He is just like the other
>>> widiots in here: A typical Snit. Dishonest to the bone
>>
>>
>> 3.5 secs sounds reasonable, if this is his drive.
>>
>>
> http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/ssd850pro/specifications.html
>>
>> Performance**	Sequential Read	Max. 550 MB/s
>> Sequential Write**
>> Max. 520 MB/s (256 GB/512 GB/1 TB/2 TB)
>> Max. 470 MB/s (128 GB)
>
> So how do you propose being able to copy 3.5 GB in 3.5 seconds when the
> drive needs 7 seconds just to read the data? Much less write it again.
>
> Your poor math capabilities show their ugly head again. Face it, you can't
> add even simple numbers. With complex stuff you are completely lost
>


What will you do when Relf posts a vid of it happening in 3.5 seconds? 
Run away like you always do and pretend you didn't see the proof.  Idiot.

Relf, could you time the file copy operation in PowerShell and put 
Dumbkopf in his place:

PS $ measure-command {copy-item bigFile.iso bigFileNew.iso}


(when you do such a copy on Linux/ext4, I bet it runs 30% slower)

[toc] | [prev] | [next] | [standalone]

#351278 — The first copy ( of a 4 gig file ) takes 11 seconds.

You ( Mr. DFS ) replied ( to Peter Köhlmann ):
> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when the
> > drive needs 7 seconds just to read the data? Much less write it again.
> 
> What will you do when Relf posts a vid of it happening in 3.5 seconds? 

As it turns out, the first copy ( of a 4 gig file ) takes 11 seconds;
subsequent copies take less than 3 seconds.

I don't know why or how.   I've got 16 gigs of 1.9 GigHz RAM.

[toc] | [prev] | [next] | [standalone]

#351302 — Re: The first copy ( of a 4 gig file ) takes 11 seconds.

 wrote:

> You ( Mr. DFS ) replied ( to Peter Köhlmann ):
>> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when the
>> > drive needs 7 seconds just to read the data? Much less write it again.
>> 
>> What will you do when Relf posts a vid of it happening in 3.5 seconds?
> 
> As it turns out, the first copy ( of a 4 gig file ) takes 11 seconds;

It naturally does. You can't bypass the physical limitations of the drive

> subsequent copies take less than 3 seconds.

Wrong. They /seem/ to happen in 3 seconds. In reality, you are 
reading/writing to buffers in RAM which happened to get filled with the 
first read/write. The real read/write still takes those 11 seconds, only it 
happens in the background now. Trip the power supply when windows says it is 
done and see your data vanish in a puff of smoke, as it is not yet written

> I don't know why or how. 

Naturally you don't. You are a windows user. In short, you are stupid

> I've got 16 gigs of 1.9 GigHz RAM.

See? Lots of buffer. Even windows by now is using at least part of the RAM 
in a intelligent way (as linux did much longer). Which is: Fill all RAM not 
needed by Programs and their data with stuff buffered from disk. Chances 
are, it will be needed again

[toc] | [prev] | [next] | [standalone]

#351309 — Re: The first copy ( of a 4 gig file ) takes 11 seconds.

On Fri, 22 Apr 2016 23:27:46 +0200, Peter Köhlmann wrote:

>  wrote:
> 
>> You ( Mr. DFS ) replied ( to Peter Köhlmann ):
>>> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when the
>>> > drive needs 7 seconds just to read the data? Much less write it again.
>>> 
>>> What will you do when Relf posts a vid of it happening in 3.5 seconds?
>> 
>> As it turns out, the first copy ( of a 4 gig file ) takes 11 seconds;
> 
> It naturally does. You can't bypass the physical limitations of the drive
> 
>> subsequent copies take less than 3 seconds.
> 
> Wrong. They /seem/ to happen in 3 seconds. In reality, you are 
> reading/writing to buffers in RAM which happened to get filled with the 
> first read/write. The real read/write still takes those 11 seconds, only it 
> happens in the background now. Trip the power supply when windows says it is 
> done and see your data vanish in a puff of smoke, as it is not yet written
> 
>> I don't know why or how. 
> 
> Naturally you don't. You are a windows user. In short, you are stupid
> 
>> I've got 16 gigs of 1.9 GigHz RAM.
> 
> See? Lots of buffer. Even windows by now is using at least part of the RAM 
> in a intelligent way (as linux did much longer). Which is: Fill all RAM not 
> needed by Programs and their data with stuff buffered from disk. Chances 
> are, it will be needed again

One word:
Cache.

Same reason from a fresh boot a given program starts in x seconds and
after quitting the program and starting again it starts in x-y
seconds.

-- 
RK

[toc] | [prev] | [next] | [standalone]

#351314 — Re: The first copy ( of a 4 gig file ) takes 11 seconds.

Richard King wrote:

> On Fri, 22 Apr 2016 23:27:46 +0200, Peter Köhlmann wrote:
> 
>>  wrote:
>> 
>>> You ( Mr. DFS ) replied ( to Peter Köhlmann ):
>>>> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when
>>>> > the drive needs 7 seconds just to read the data? Much less write it
>>>> > again.
>>>> 
>>>> What will you do when Relf posts a vid of it happening in 3.5 seconds?
>>> 
>>> As it turns out, the first copy ( of a 4 gig file ) takes 11 seconds;
>> 
>> It naturally does. You can't bypass the physical limitations of the drive
>> 
>>> subsequent copies take less than 3 seconds.
>> 
>> Wrong. They /seem/ to happen in 3 seconds. In reality, you are
>> reading/writing to buffers in RAM which happened to get filled with the
>> first read/write. The real read/write still takes those 11 seconds, only
>> it happens in the background now. Trip the power supply when windows says
>> it is done and see your data vanish in a puff of smoke, as it is not yet
>> written
>> 
>>> I don't know why or how.
>> 
>> Naturally you don't. You are a windows user. In short, you are stupid
>> 
>>> I've got 16 gigs of 1.9 GigHz RAM.
>> 
>> See? Lots of buffer. Even windows by now is using at least part of the
>> RAM in a intelligent way (as linux did much longer). Which is: Fill all
>> RAM not needed by Programs and their data with stuff buffered from disk.
>> Chances are, it will be needed again
> 
> One word:
> Cache.

Other word: Buffer

And now go playing on the highway

[toc] | [prev] | [next] | [standalone]

#351325 — Re: The first copy ( of a 4 gig file ) takes 11 seconds.

On Sat, 23 Apr 2016 00:05:11 +0200, Peter Köhlmann wrote:

> Richard King wrote:
> 
>> On Fri, 22 Apr 2016 23:27:46 +0200, Peter Köhlmann wrote:
>> 
>>>  wrote:
>>> 
>>>> You ( Mr. DFS ) replied ( to Peter Köhlmann ):
>>>>> > So how do you propose being able to copy 3.5 GB in 3.5 seconds when
>>>>> > the drive needs 7 seconds just to read the data? Much less write it
>>>>> > again.
>>>>> 
>>>>> What will you do when Relf posts a vid of it happening in 3.5 seconds?
>>>> 
>>>> As it turns out, the first copy ( of a 4 gig file ) takes 11 seconds;
>>> 
>>> It naturally does. You can't bypass the physical limitations of the drive
>>> 
>>>> subsequent copies take less than 3 seconds.
>>> 
>>> Wrong. They /seem/ to happen in 3 seconds. In reality, you are
>>> reading/writing to buffers in RAM which happened to get filled with the
>>> first read/write. The real read/write still takes those 11 seconds, only
>>> it happens in the background now. Trip the power supply when windows says
>>> it is done and see your data vanish in a puff of smoke, as it is not yet
>>> written
>>> 
>>>> I don't know why or how.
>>> 
>>> Naturally you don't. You are a windows user. In short, you are stupid
>>> 
>>>> I've got 16 gigs of 1.9 GigHz RAM.
>>> 
>>> See? Lots of buffer. Even windows by now is using at least part of the
>>> RAM in a intelligent way (as linux did much longer). Which is: Fill all
>>> RAM not needed by Programs and their data with stuff buffered from disk.
>>> Chances are, it will be needed again
>> 
>> One word:
>> Cache.
> 
> Other word: Buffer
> 
> And now go playing on the highway

Buffer is sometimes referred to buffer cache.
You know what I meant.

Let's make it simple so even you can understand.

The data is already loaded/stored "somewhere" so it doesn't have to be
retrieved again from physical disk.

Now go play in traffic, again.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.advocacy

csiph-web