Phillip Helbig---remove CLOTHES to reply wrote:
> a shadow copy, but the bottleneck there is the 5 Mb/s SCSI of the VAXes.
> However, I have a 6 Mb/s DSL connection and it would be nice to be able
> to use that speed, especially when running CSWB on the 5305.


5 megabytes per seconds != 6 megabits per seconds.


> My ISP has a web page where one can test the current speed. From the
> PC, I get the advertised 6 Mb/s.

Most DSL providers actually provide ADSL. High speed from the net to
you, but low speed from you to the net.

Here, I get 3Mb/s up, only 800kbs down. (rumours that the telco will
upgrade to 5mbps soon)

> I connected the 5305 directly to the switch and booted it. It still
> functioned OK in the cluster. However, the speed indicated by my ISP
> was still the slow one,

Most DSL modems only talk at 10mbps since it is more than enough.

Phillip Helbig---remove CLOTHES to reply wrote:
> I connected the 5305 directly to the switch and booted it. It still
> functioned OK in the cluster. However, the speed indicated by my ISP
> was still the slow one, and also the "full" and "100" lights did not
> light up on the switch. I was hoping that, even if it has to
> communicate with my cluster at 10 Mb/s half duplex, perhaps it could
> communicate with the internet at 100 Mb/s full duplex. That doesn't
> seem to be the case, though.
>

Make sure that the SRM console setting for the NIC have been changed.
It's probably a DEC DE500 family card and they are notorious for
having problems doing an auto-negotiate. Some switches they will
auto-negotiate fine with and others they will not. If you had it
attached to a 10Mbs hub then it's probably set to "Twisted-Pair" which
defaults to 10Mbs/Half Duplex. When you attach it to the 100Mbs switch
you want to set it to "FastFD" (>>> set ewa0_mode fastfd) otherwise the
switch will just match itself to the NIC and you won't see any speed
increase.

> Of course, it still has to communicate with the cluster at the slow
> speed. Maybe that slows down ALL traffic on its ethernet card.
>

No. The switch should handle all of that. If the settings are right
it will talk to the 5305 at 100Mbs and buffer it to send to the hub at
10Mbs. Automagically.

> Replacing my 10 Mb/s hub with a 10 Mb/s switch would offer only a
> minimal improvement. Would it make sense to replace it with a 100 Mb/s
> hub or switch? (If I buy something new, it might as well be a switch.)

You want a switch. Even a dumb 100Mbs switch is minimally more than a
hub and it will benefit all of your systems. A switch is much smarter
than a hub in that they memorize the MAC addresses at each port and
will only send data packets to the port required for its destination.
This means that systems do not see traffic that is not going to them
and it reduces the load on the NIC/system. Plus with a hub the
bandwidth is shared among all ports whereas with a switch you get the
full 100Mbs on each port (overkill, I know, for the VAXen).

> (Of course, it would have to be capable of negotiating at 10 Mb/s as
> well.)

It's rare to find a modern 100Mbs switch that can't.

>
> Of course, this assumes that the 5305 is capable of 100 Mb/s and/or full
> duplex.

I believe most AS1200/DEV5305's shipped with the DE500 NIC which is
100Mbs/Full capable. There is a chance that if you got an early one it
may have a DE450 which is 10Mbs only. Check the output of a "Show
config" on the console sometime if you're not sure.


>
> I would like to have the 5305 communicate with the internet at 6 Mb/s
> (or more, if I have a faster connection in the future) even if it has to
> communicate with the cluster at 10 Mb/s. One way around this might be
> to have two ethernet cards in the 5305 and use one for cluster
> communication and one for ethernet communication, but that would be a
> lot of work, I have no experience with that and it would provide no
> performance improvement at all for the rest of the cluster (except for
> reducing the number of collisions somewhat).
>
> I had hoped that plugging the 5305 directly into the switch, with the
> rest of the nodes in the cluster connected to a hub uplinked to the
> switch, would allow the 5305 to communicate faster with the internet,
> but apparently that's not the case.
>

Again, double check your console setting for ewa0_mode. It should be
FastFD if you connect to the switch and Twisted-Pair f it's attached to
the 10Mbs hub. You could try the Auto-Negotiate setting but I don't
think it works for a DE500 (if that's what you have).

Also you can check what your connections is while VMS is running
through the LanCP utility.

$ mcr lancp
LANCP> show dev /char eia0

Device Characteristics EIA0:
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-50-8B-E3-A2-9E Hardware LAN address
Multicast address list
CSMA/CD Communication medium
FF-FF-FF-FF-FF-FF Current LAN address
128 Minimum receive buffers
256 Maximum receive buffers
Yes Full duplex enable
Yes Full duplex operational
00-50-8B-E3-A2-9E Current LAN address
TwistedPair Line media type
100 Line speed (mbps)
Enabled Auto-negotiation
Enabled Flow control
Disabled Jumbo frames
Disabled/No Failset Logical LAN state
0 Failover priority
LANCP>

Note the "Line speed", "Full duples enable" and "Full duplex
operational" values to see how the NIC is connecting under VMS.

> Of course, if bandwidth-splitting is the main problem, then a faster
> internet connection would present a larger pie to be split up among the
> various connections, but naturally it would be better for one node to
> make full use of the high speed if there is no other traffic.
>
>
> Cheers,
>
> Phillip

wrote in message
news:1148646366.388202.151640@j33g2000cwa.googlegr oups.com...

> When you attach it to the 100Mbs switch you want to set it to "FastFD"
> (>>> set ewa0_mode fastfd) otherwise the switch will just match itself
> to the NIC and you won't see any speed increase.

Word of warning: never set *one* end of a connection to full duplex.
If you can't manually set both ends, and are unwilling to trust autonegotiation,
set it to half duplex.

writes:

> Make sure that the SRM console setting for the NIC have been changed.
> It's probably a DEC DE500 family card and they are notorious for
> having problems doing an auto-negotiate. Some switches they will
> auto-negotiate fine with and others they will not. If you had it
> attached to a 10Mbs hub then it's probably set to "Twisted-Pair" which
> defaults to 10Mbs/Half Duplex. When you attach it to the 100Mbs switch
> you want to set it to "FastFD" (>>> set ewa0_mode fastfd) otherwise the
> switch will just match itself to the NIC and you won't see any speed
> increase.

The above info is not quite right. The DE500-BA and -AA should have no problem
autonegotiating with a correctly-behaving switch (this is coming from the
guy who supports the LAN drivers for VMS [that's not me; I'm just passing that
statement along]). If you have a problem with one of these card with respect
to autonegotiation (and you are running a reasonably-current version of VMS
with recent patches), it's likely a switch problem, not a card problem.


For those who will choose to upgrade to V8.3, you can take advantage of this
updated display (this is not in the field test version) . . .

There are some subtle differences between the display for a template device
and a device that is protocol-specific.


SISKO Alpha> sho dev/full ewb0

Device EWB0:, device type DEGPA, is online, network device, error logging is
enabled, device is a template only.

Error count 1 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 0 Default buffer size 512
Current preferred CPU Id 1 Fastpath 1

Operating characteristics: Link up, Full duplex, Autonegotiation, Jumbo frames.

Speed (Mbits/sec) 1000
Def. MAC addr 00-60-6D-21-1E-DF Current MAC addr 00-60-6D-21-1E-DF

SISKO Alpha> sho dev ewa7/ful

Device EWA7:, device type DE500, is online, network device, error logging is
enabled.

Error count 0 Operations completed 118332
Owner process "NETACP" Owner UIC [SYSTEM]
Owner process ID 40200423 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 2 Default buffer size 1498

Operating characteristics: Full duplex, Autonegotiation.

Speed (Mbits/sec) 100
Def. MAC addr 00-00-F8-1F-46-6F Current MAC addr AA-00-04-00-4A-FD
Protocol name DECNET Protocol type 60-03

--

Rob Brooks VMS Engineering -- Exec Group brooks!cuebid.zko.hp.com

Rob Brooks wrote:
> writes:
>
> > Make sure that the SRM console setting for the NIC have been changed.
> > It's probably a DEC DE500 family card and they are notorious for
> > having problems doing an auto-negotiate. Some switches they will
> > auto-negotiate fine with and others they will not. If you had it
> > attached to a 10Mbs hub then it's probably set to "Twisted-Pair" which
> > defaults to 10Mbs/Half Duplex. When you attach it to the 100Mbs switch
> > you want to set it to "FastFD" (>>> set ewa0_mode fastfd) otherwise the
> > switch will just match itself to the NIC and you won't see any speed
> > increase.
>
> The above info is not quite right. The DE500-BA and -AA should have no problem
> autonegotiating with a correctly-behaving switch (this is coming from the
> guy who supports the LAN drivers for VMS [that's not me; I'm just passing that
> statement along]). If you have a problem with one of these card with respect
> to autonegotiation (and you are running a reasonably-current version of VMS
> with recent patches), it's likely a switch problem, not a card problem.
>

I stand corrected. :-) My troubles with these were some time ago back
in the V6.2/V7.0 timeframe. Probably a combination of early switches
and new NIC drivers.

>
> For those who will choose to upgrade to V8.3, you can take advantage of this
> updated display (this is not in the field test version) . . .
>
> There are some subtle differences between the display for a template device
> and a device that is protocol-specific.
>
>
> SISKO Alpha> sho dev/full ewb0
>
> Device EWB0:, device type DEGPA, is online, network device, error logging is
> enabled, device is a template only.
>
> Error count 1 Operations completed 0
> Owner process "" Owner UIC [SYSTEM]
> Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
> Reference count 0 Default buffer size 512
> Current preferred CPU Id 1 Fastpath 1
>
> Operating characteristics: Link up, Full duplex, Autonegotiation, Jumbo frames.
>
> Speed (Mbits/sec) 1000
> Def. MAC addr 00-60-6D-21-1E-DF Current MAC addr 00-60-6D-21-1E-DF
>
> SISKO Alpha> sho dev ewa7/ful
>
> Device EWA7:, device type DE500, is online, network device, error logging is
> enabled.
>
> Error count 0 Operations completed 118332
> Owner process "NETACP" Owner UIC [SYSTEM]
> Owner process ID 40200423 Dev Prot S:RWPL,O:RWPL,G,W
> Reference count 2 Default buffer size 1498
>
> Operating characteristics: Full duplex, Autonegotiation.
>
> Speed (Mbits/sec) 100
> Def. MAC addr 00-00-F8-1F-46-6F Current MAC addr AA-00-04-00-4A-FD
> Protocol name DECNET Protocol type 60-03
>

That's great. Shows pretty much all the of the typical things you'd
want to know in one display.

Rob Brooks wrote:

> writes:
>
>
>>Make sure that the SRM console setting for the NIC have been changed.
>> It's probably a DEC DE500 family card and they are notorious for
>>having problems doing an auto-negotiate. Some switches they will
>>auto-negotiate fine with and others they will not. If you had it
>>attached to a 10Mbs hub then it's probably set to "Twisted-Pair" which
>>defaults to 10Mbs/Half Duplex. When you attach it to the 100Mbs switch
>>you want to set it to "FastFD" (>>> set ewa0_mode fastfd) otherwise the
>>switch will just match itself to the NIC and you won't see any speed
>>increase.
>
>
> The above info is not quite right. The DE500-BA and -AA should have no problem
> autonegotiating with a correctly-behaving switch (this is coming from the
> guy who supports the LAN drivers for VMS [that's not me; I'm just passing that
> statement along]). If you have a problem with one of these card with respect
> to autonegotiation (and you are running a reasonably-current version of VMS
> with recent patches), it's likely a switch problem, not a card problem.
>

I'm no longer able to verify this but I seem to recall having to force
the Fast FD setting with DE500-AA NICs and and a relatively modern Cisco
Switch (Catalyst 6500????). I no longer work there so I can't go look
and can't swear to the model.

I thought that the autonegotiation stuff was hardware/firmware level
rather than VMS driver level. Not so? The systems in question were
running VMS V6.2-1H3 and V7.2-1.

JF Mezei wrote:
> Phillip Helbig---remove CLOTHES to reply wrote:
>
>
>>My ISP has a web page where one can test the current speed. From the
>>PC, I get the advertised 6 Mb/s.
>
>
> Most DSL providers actually provide ADSL. High speed from the net to
> you, but low speed from you to the net.
>
> Here, I get 3Mb/s up, only 800kbs down. (rumours that the telco will
> upgrade to 5mbps soon)
>

If the telco does upgrade, make sure you ask for it. I say this since my
cable company has just upgraded their standard package to 3000/256 kbs,
and my latest bill says that's what I'm on, but my connection is still
only giving me the previous. slower, speeds.

In article <8c7cd$447832e2$50db5015$22322@news.hispeed.ch>,
Paul Sture wrote:
>JF Mezei wrote:
>> Phillip Helbig---remove CLOTHES to reply wrote:
>>
>>
>>>My ISP has a web page where one can test the current speed. From the
>>>PC, I get the advertised 6 Mb/s.
>>
>>
>> Most DSL providers actually provide ADSL. High speed from the net to
>> you, but low speed from you to the net.
>>
>> Here, I get 3Mb/s up, only 800kbs down. (rumours that the telco will
>> upgrade to 5mbps soon)
>>
>
>If the telco does upgrade, make sure you ask for it. I say this since my
>cable company has just upgraded their standard package to 3000/256 kbs,
>and my latest bill says that's what I'm on, but my connection is still
>only giving me the previous. slower, speeds.


One thing I've seen is that the cable modem needs to have it's settings
reloaded for the higher speed. Although they could reprogram them all
on a schedule from the head end, it seems they tell you to power them
off so they get the new settings on their reload. That way they don't
get extra work beyond making the change in the provisioning system.

Every so often (6 months or so) I power mine off to clear it in case
they've slipstreamed in some more upgrades.

I put the damned thing on a UPS along with the firewall Linux box,
my ethernet switches, cordless phones and my voip box so local thunderstorms
don't drop me 5 times a week.

Bill

--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-ureachtechnologies.com

Paul Sture wrote:
> If the telco does upgrade, make sure you ask for it. I say this since my
> cable company has just upgraded their standard package to 3000/256 kbs,
> and my latest bill says that's what I'm on, but my connection is still
> only giving me the previous. slower, speeds.

DSL is very different from DOCSIS cable modems in that respect.

When a DOCSIS modem is powered up, it uses BOOTP/TFTP (or eequivalent)
to fetch its configuration from the ISP over the coax. This config gives
lots of parameters, including speeds, number of devices that are allowed
to talk via the modem, various ISP filters etc etc.

Once it has received its config, the modem is good to go "forever".

ISPs may upgrade your profile, but that won't take effect until the
modem next reboots and asks for a new copy of its parameters. ISPs can
remotely trigger this process, but they often don't because this would
put quite a strain on their TFTP/BOOTP servers and also all customers
would get the upgrade at the same time and it would be a big change on
the network. By waiting for customers to eventually power off/on their
modems, the upgrade is effectively spread over a longer period of time
and the ISP can gauge the impact on its network.

With DSL, upgrades are done by changing the config at the central office
and as soon as they do this, the modems at the CO and homes renegotiate
the speed to the new setting. So the actual upgrades have to be
staggered. And they work from CO to CO. The problem with DSL is that not
all customers are technically able to get the upgrade so it requires a
bit more finesse with their scripts to upgrade only those whose line
quality is good enough.

On 2006-05-27, JF Mezei wrote:
> Paul Sture wrote:
>> If the telco does upgrade, make sure you ask for it. I say this since my
>> cable company has just upgraded their standard package to 3000/256 kbs,
>> and my latest bill says that's what I'm on, but my connection is still
>> only giving me the previous. slower, speeds.
>
> With DSL, upgrades are done by changing the config at the central office
> and as soon as they do this, the modems at the CO and homes renegotiate
> the speed to the new setting. So the actual upgrades have to be
> staggered. And they work from CO to CO. The problem with DSL is that not
> all customers are technically able to get the upgrade so it requires a
> bit more finesse with their scripts to upgrade only those whose line
> quality is good enough.

Then you mix in some marketing and too much traffic for the telco equipment,
and customers can see that their line WOULD have the quality for the higher
speed, but "somehow" they won't get more while still paying for the higher
speed. And on top of it, they opened the pipes and put in software traffic
shapers, so you can't be sure of where the problem lies.

But then again I guess this is typical behaviour for telco companies.

Thierry

In article <20060526123151.0bd258d0.hoendech@ecc.lu>, Stefaan A Eeckels
writes:

> On Fri, 26 May 2006 07:50:19 +0000 (UTC)
> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
> reply) wrote:
>
> > I had been asking about whether it was worth it to replace my hub
> > with a switch. For the VAXes, probably not, since when I need speed
> > is during a shadow copy, but the bottleneck there is the 5 Mb/s SCSI
> > of the VAXes.
>
> Even SCSI-1 is capable of 5MB/s or 40Mb/s throughput:

OK, I was assuming it was 5 Mb/s and you are saying it is 5 MB/s.

Bill Pechter wrote:

>
> One thing I've seen is that the cable modem needs to have it's settings
> reloaded for the higher speed. Although they could reprogram them all
> on a schedule from the head end, it seems they tell you to power them
> off so they get the new settings on their reload. That way they don't
> get extra work beyond making the change in the provisioning system.
>
> Every so often (6 months or so) I power mine off to clear it in case
> they've slipstreamed in some more upgrades.
>

A good idea Bill, although rebooting both the cable modem and router
have not resulted in a change.


> I put the damned thing on a UPS along with the firewall Linux box,
> my ethernet switches, cordless phones and my voip box so local thunderstorms
> don't drop me 5 times a week.
>

Ouch.

Thierry Dussuet wrote:
> On 2006-05-27, JF Mezei wrote:
>
>>Paul Sture wrote:
>>
>>>If the telco does upgrade, make sure you ask for it. I say this since my
>>>cable company has just upgraded their standard package to 3000/256 kbs,
>>>and my latest bill says that's what I'm on, but my connection is still
>>>only giving me the previous. slower, speeds.
>>
>>With DSL, upgrades are done by changing the config at the central office
>>and as soon as they do this, the modems at the CO and homes renegotiate
>>the speed to the new setting. So the actual upgrades have to be
>>staggered. And they work from CO to CO. The problem with DSL is that not
>>all customers are technically able to get the upgrade so it requires a
>>bit more finesse with their scripts to upgrade only those whose line
>>quality is good enough.
>

When I was on ADSL, I didn't have a problem with upgrades, but I must
mentions that I was on a business rather than consumer contract.

>
> Then you mix in some marketing and too much traffic for the telco equipment,
> and customers can see that their line WOULD have the quality for the higher
> speed, but "somehow" they won't get more while still paying for the higher
> speed. And on top of it, they opened the pipes and put in software traffic
> shapers, so you can't be sure of where the problem lies.
>

A few months ago I measured the up/down speed of a friend who had taken
the step of paying more for an upgraded service. Still on the old speed. :-(

> But then again I guess this is typical behaviour for telco companies.
>

I cannot disagree there.

On Mon, 29 May 2006 20:25:02 +0000 (UTC)
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
reply) wrote:

> In article <20060526123151.0bd258d0.hoendech@ecc.lu>, Stefaan A
> Eeckels writes:
>
> > On Fri, 26 May 2006 07:50:19 +0000 (UTC)
> > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
> > reply) wrote:
> >
> > > I had been asking about whether it was worth it to replace my hub
> > > with a switch. For the VAXes, probably not, since when I need
> > > speed is during a shadow copy, but the bottleneck there is the 5
> > > Mb/s SCSI of the VAXes.
> >
> > Even SCSI-1 is capable of 5MB/s or 40Mb/s throughput:
>
> OK, I was assuming it was 5 Mb/s and you are saying it is 5 MB/s.

Indeed. You will probably find that upgrading to 100Mb/s speeds up the
transfers, especially if you use a switch instead of a hub and ensure
you're in full duplex.

Take care,

--
Stefaan A Eeckels
--
Isn't it amazing how a large number of evil morons can give the
appearance of being a single evil genius? --Mel Rimmer

Rob Brooks wrote:
> writes:
>
>> Make sure that the SRM console setting for the NIC have been changed.
>> It's probably a DEC DE500 family card and they are notorious for
>> having problems doing an auto-negotiate. Some switches they will
>> auto-negotiate fine with and others they will not.
...
> The above info is not quite right. The DE500-BA and -AA should have no problem
> autonegotiating with a correctly-behaving switch...

Details on the four DE500 variants and on auto-negotiate are in the
OpenVMS FAQ:

--

I still believe that the base limit here is that the VAX systems are
correspondingly slow by any current standards (well, by any standards
other than the "free hardware" standard, and even that one is certainly
debatable :-), and this hardware configuration is attempting to slam
large volumes of data (shadow disk copies, et al) over a very slow IEEE
802.3 (AKA Ethernet; 1MB, 10Mb) network link -- and you won't get
anywhere near all of the 802.3 link, for that matter. The fastest
network switch in existence just won't make typical VAX hardware
configuration operate any faster.

In article , Hoff Hoffman
writes:

> I still believe that the base limit here is that the VAX systems are
> correspondingly slow by any current standards (well, by any standards
> other than the "free hardware" standard, and even that one is certainly
> debatable :-),

That's certainly true.

> and this hardware configuration is attempting to slam
> large volumes of data (shadow disk copies, et al) over a very slow IEEE
> 802.3 (AKA Ethernet; 1MB, 10Mb) network link -- and you won't get
> anywhere near all of the 802.3 link, for that matter. The fastest
> network switch in existence just won't make typical VAX hardware
> configuration operate any faster.

Right. However, I'm hoping for two things: 1) WHEN the VAXes saturate
the network with the shadow copies, perhaps this could be isolated from
other systems by avoiding collisions and 2) the one node in the cluster
which IS reasonably fast (5305/AS1200) should be able to run at 100 Mb/s
and full duplex to make the most of the internet connection, especially
considering that this node is a satellite which is only booted when I
(or my wife) needs Mozilla.

In message
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove
CLOTHES to reply) wrote:

> In article , Hoff Hoffman
> writes:
>
>> I still believe that the base limit here is that the VAX systems are
>> correspondingly slow by any current standards (well, by any standards
>> other than the "free hardware" standard, and even that one is certainly
>> debatable :-),
>
> That's certainly true.
>
>> and this hardware configuration is attempting to slam
>> large volumes of data (shadow disk copies, et al) over a very slow IEEE
>> 802.3 (AKA Ethernet; 1MB, 10Mb) network link -- and you won't get
>> anywhere near all of the 802.3 link, for that matter. The fastest
>> network switch in existence just won't make typical VAX hardware
>> configuration operate any faster.
>
> Right. However, I'm hoping for two things: 1) WHEN the VAXes saturate
> the network with the shadow copies, perhaps this could be isolated from
> other systems by avoiding collisions and 2) the one node in the cluster
> which IS reasonably fast (5305/AS1200) should be able to run at 100 Mb/s
> and full duplex to make the most of the internet connection, especially
> considering that this node is a satellite which is only booted when I
> (or my wife) needs Mozilla.

If you connect everything to a switch instead of a repeater

1: The VAX won't saturate the network, only its own connection to the
switch
2: The shadow copy traffic will only exist on the two connections
participating in the copy
3: The other systems will be able to operate at full speed
concurrently, provided they don't use one of the links involved in the
shadow copy.

If you use more than one switch, be careful that the link between the
switches doesn't become the new bottleneck. Put the systems involved
in the shadow copy on one switch, and the most important of the
remaining systems plus the internet connection on the other switch.

--
Alan Adams, from Northamptonshire
alan.adams@orchard-way.freeserve.co.uk
http://www.nckc.org.uk/

> > Right. However, I'm hoping for two things: 1) WHEN the VAXes saturate
> > the network with the shadow copies, perhaps this could be isolated from


Ok, basic question here: can a VAX saturate a 10 mbps ethernet ?

When a 4000-200 does a backup of a disk served by a VS 3100-30, the
3100's CPU goes to nearly 100% due to the MSCP server.

Maybe next time, I should use ethermon on a 3rd node to watch just how
much traffic flows. I would assume that a backup woudl actually suck up
more of the ethernet since it is only reading from the disk and not
waiting for a write confirmation.