I've bought a new disk (HDD, WD purple) but instead of
replacing the old, I disconnected internal DVD recorder and
I moved the old one there (I had no spare "molex" nor esata
channels left).
Now I have found a strange thing : the timing of the facts
is too suspicious to be decorrelated : my USB alcatel model
fails to be charged at a pace fast enough to keep up with
battery consumption and after 1-2 hours of intense use,
switches off.

I am thinking the power (we call it "alimentatore" but dunno
the English word ... the power source, let's say) is
insufficient to cover up all devices properly and fails to
send enough current to external devices (the HDD behaves
normally)

now the true question (The drive currently is mounted via FSTAB)

would unmount the drive cause it to stop spinning ?

There is a faster way to sendo some low level command to
make it stop spinning ? I.g. some "IOCTL" sequence.

the /dev/sde1 interface for the block device can receive
IOCTLs codes (assuming I'd be able to find proper commands
to send to the controller).

The drive will be seldom used (I don't have a big enough
extern box to build an USB unit)

I'd largely prefer to send direct commands to stop spinning
and park the heads to unmounting (assumed unmounting will
cut power consumption, thing that I dunno, actually), since
later the drive would still be responding requests,
automatically restarting spinning on receiving requests, I
guess.


for those really knowledgeable in internal Linux working :
does a drive not actively used (no files opened, no file
manager operating on it) require some form of "polling" its
state that would cause frequent automatical restartig of
spinning ? In this case, stopping it would be harmful and
enhance preature wearing of the motors and all and it would
have no benefit to manually stop spinning.

I ask this latter because I have an INTENSO 4 TB external
drive (a monster of speed, it reaches 160 MB/s !) that on
another machine (always debian / MX) frequently stops and
later at some time for no apparent reason at all restarts
spinning (there the blue led makes it further evident beyond
the ears can probe). Now surely it could be the internal
"controller" aggressive power saving strategies, independent
on the OS, to switch the drive off even if no "warranty" of
no further requests was given by the OS (unmounting for
examople).
But that is an USB external device and such strategies seem
reasonable.

I dunno if a drive connected on esata and molex is allowed
to decide alike (or if the OS can / must somehow save power
if the disk is not in active use).

If sb knows about this topic, pls share opinions.

tnx

-- CCCPMario or MarioCCCP

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 29.09.2023 schrieb Fonntuggnio <JoeFonntuggnio@libbbero.it>:

I've bought a new disk (HDD, WD purple) but instead of
replacing the old, I disconnected internal DVD recorder and
I moved the old one there (I had no spare "molex" nor esata
channels left).
Now I have found a strange thing : the timing of the facts
is too suspicious to be decorrelated : my USB alcatel model
fails to be charged at a pace fast enough to keep up with
battery consumption and after 1-2 hours of intense use,
switches off.

Seems to be an USB problem. A bus has limited amperage.

would unmount the drive cause it to stop spinning ?

Not directly. Even when it is mounted it can be spinned down and
spinned up again when needed.

There is a faster way to sendo some low level command to
make it stop spinning ? I.g. some "IOCTL" sequence.

hdparm https://superuser.com/questions/852727/safe-to-manually-spin-down-hard-drive-with-hdparm

for those really knowledgeable in internal Linux working :
does a drive not actively used (no files opened, no file
manager operating on it) require some form of "polling" its
state that would cause frequent automatical restartig of
spinning ? In this case, stopping it would be harmful and
enhance preature wearing of the motors and all and it would
have no benefit to manually stop spinning.

Every read request (not in cache) will cause it to spin up.
Write request can be cached and will be synced at unmount (can be
invoked by "sync").

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/09/23 10:56, Marco Moock wrote:

Am 29.09.2023 schrieb Fonntuggnio <JoeFonntuggnio@libbbero.it>:

I've bought a new disk (HDD, WD purple) but instead of
replacing the old, I disconnected internal DVD recorder and
I moved the old one there (I had no spare "molex" nor esata
channels left).
Now I have found a strange thing : the timing of the facts
is too suspicious to be decorrelated : my USB alcatel model
fails to be charged at a pace fast enough to keep up with
battery consumption and after 1-2 hours of intense use,
switches off.

Seems to be an USB problem. A bus has limited amperage.

would unmount the drive cause it to stop spinning ?

Not directly. Even when it is mounted it can be spinned down and
spinned up again when needed.

There is a faster way to sendo some low level command to
make it stop spinning ? I.g. some "IOCTL" sequence.

hdparm https://superuser.com/questions/852727/safe-to-manually-spin-down-hard-drive-with-hdparm

tnx for this very prompt reply ! I'll study the case

for those really knowledgeable in internal Linux working :
does a drive not actively used (no files opened, no file
manager operating on it) require some form of "polling" its
state that would cause frequent automatical restartig of
spinning ? In this case, stopping it would be harmful and
enhance preature wearing of the motors and all and it would
have no benefit to manually stop spinning.

Every read request (not in cache) will cause it to spin up.
Write request can be cached and will be synced at unmount (can be
invoked by "sync").

tnx !

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/09/23 12:12, MarioCCCP wrote:

On 29/09/23 10:56, Marco Moock wrote:

Am 29.09.2023 schrieb Fonntuggnio
<JoeFonntuggnio@libbbero.it>:

I've bought a new disk (HDD, WD purple) but instead of
replacing the old, I disconnected internal DVD recorder and
I moved the old one there (I had no spare "molex" nor esata
channels left).
Now I have found a strange thing : the timing of the facts
is too suspicious to be decorrelated : my USB alcatel model
fails to be charged at a pace fast enough to keep up with
battery consumption and after 1-2 hours of intense use,
switches off.

Seems to be an USB problem. A bus has limited amperage.

would unmount the drive cause it to stop spinning ?

Not directly. Even when it is mounted it can be spinned
down and
spinned up again when needed.

There is a faster way to sendo some low level command to
make it stop spinning ? I.g. some "IOCTL" sequence.

hdparm
https://superuser.com/questions/852727/safe-to-manually-spin-down-hard-drive-with-hdparm

tnx for this very prompt reply ! I'll study the case

for those really knowledgeable in internal Linux working :
does a drive not actively used (no files opened, no file
manager operating on it) require some form of "polling" its
state that would cause frequent automatical restartig of
spinning ? In this case, stopping it would be harmful and
enhance preature wearing of the motors and all and it would
have no benefit to manually stop spinning.

Every read request (not in cache) will cause it to spin up.
Write request can be cached and will be synced at unmount
(can be
invoked by "sync").

tnx !

in the replies of the SuperUser thread you signalled, I
found the HD-IDLE utility that does exactly what I required
!!! Wonderful Linux

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-29 10:43, Fonntuggnio wrote:

I've bought a new disk (HDD, WD purple) but instead of replacing the
old, I disconnected internal DVD recorder and I moved the old one there
(I had no spare "molex" nor esata channels left).
Now I have found a strange thing : the timing of the facts is too
suspicious to be decorrelated : my USB alcatel model fails to be charged
at a pace fast enough to keep up with battery consumption and after 1-2
hours of intense use, switches off.

I am thinking the power (we call it "alimentatore" but dunno the English
word ... the power source, let's say) is insufficient to cover up all
devices properly and fails to send enough current to external devices
(the HDD behaves normally)

now the true question (The drive currently is mounted via FSTAB)

would unmount the drive cause it to stop spinning ?

Not inmediately, there is a timeout.

hdparm - get/set SATA/IDE device parameters

-C Check the current IDE power mode status, which will
always be one of unknown (drive does not support
this command), active/idle (normal operation),
standby (low power mode, drive has spun down), or
sleeping (lowest power mode, drive is completely
shut down). The -S, -y, -Y, and -Z options can be
used to manipulate the IDE power modes.

-s Enable/disable the power-on in standby feature, if
supported by the drive. VERY DANGEROUS. Do not
use unless you are absolutely certain that both the
system BIOS (or firmware) and the operating system
kernel (Linux >= 2.6.22) support probing for drives
that use this feature. When enabled, the drive is
powered-up in the standby mode to allow the con-
troller to sequence the spin-up of devices, reduc-
ing the instantaneous current draw burden when many
drives share a power supply. Primarily for use in
large RAID setups. This feature is usually dis-
abled and the drive is powered-up in the active
mode (see -C above). Note that a drive may also
allow enabling this feature by a jumper. Some SATA
drives support the control of this feature by pin
11 of the SATA power connector. In these cases,
this command may be unsupported or may have no ef-
fect.

-S Put the drive into idle (low-power) mode, and also
set the standby (spindown) timeout for the drive.
This timeout value is used by the drive to deter-
mine how long to wait (with no disk activity) be-
fore turning off the spindle motor to save power.
Under such circumstances, the drive may take as
long as 30 seconds to respond to a subsequent disk
access, though most drives are much quicker. The
encoding of the timeout value is somewhat peculiar.
A value of zero means "timeouts are disabled": the
device will not automatically enter standby mode.
Values from 1 to 240 specify multiples of 5 sec-
onds, yielding timeouts from 5 seconds to 20 min-
utes. Values from 241 to 251 specify from 1 to 11
units of 30 minutes, yielding timeouts from 30 min-
utes to 5.5 hours. A value of 252 signifies a
timeout of 21 minutes. A value of 253 sets a ven-
dor-defined timeout period between 8 and 12 hours,
and the value 254 is reserved. 255 is interpreted
as 21 minutes plus 15 seconds. Note that some
older drives may have very different interpreta-
tions of these values.

There is a faster way to sendo some low level command to make it stop spinning ? I.g. some "IOCTL" sequence.

The "-S" option above.

for those really knowledgeable in internal Linux working : does a drive
not actively used (no files opened, no file manager operating on it)
require some form of "polling" its state that would cause frequent automatical restartig of spinning ? In this case, stopping it would be harmful and enhance preature wearing of the motors and all and it would
have no benefit to manually stop spinning.

There can be operations that trigger periodically that would cause the
disk to spin up again. Typical culprits were syslog. I seem to remember
some 7 minutes timeout somewhere, just a foggy memory.

If the disk is umounted, then hardly. Well, a command such as "lsblk"
could wake up all disks, because it probes them all. Smartctl... I think
there is an option telling it to wake or not wake a sleeping disk.

--
Cheers,
Carlos E.R.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMjkvMDkvMjMgMTQ6MzgsIENhcmxvcyBFLiBSLiB3cm90ZToNCj4gT24gMjAyMy0wOS0y OSAxMDo0MywgRm9ubnR1Z2duaW8gd3JvdGU6DQo+Pg0KPj4gSSd2ZSBib3VnaHQgYSBuZXcg ZGlzayAoSERELCBXRCBwdXJwbGUpIGJ1dCBpbnN0ZWFkIG9mIA0KPj4gcmVwbGFjaW5nIHRo ZSBvbGQsIEkgZGlzY29ubmVjdGVkIGludGVybmFsIERWRCByZWNvcmRlciANCj4+IGFuZCBJ IG1vdmVkIHRoZSBvbGQgb25lIHRoZXJlIChJIGhhZCBubyBzcGFyZSAibW9sZXgiIG5vciAN Cj4+IGVzYXRhIGNoYW5uZWxzIGxlZnQpLg0KPj4gTm93IEkgaGF2ZSBmb3VuZCBhIHN0cmFu Z2UgdGhpbmcgOiB0aGUgdGltaW5nIG9mIHRoZSBmYWN0cyANCj4+IGlzIHRvbyBzdXNwaWNp b3VzIHRvIGJlIGRlY29ycmVsYXRlZCA6IG15IFVTQiBhbGNhdGVsIA0KPj4gbW9kZWwgZmFp bHMgdG8gYmUgY2hhcmdlZCBhdCBhIHBhY2UgZmFzdCBlbm91Z2ggdG8ga2VlcCB1cCANCj4+ IHdpdGggYmF0dGVyeSBjb25zdW1wdGlvbiBhbmQgYWZ0ZXIgMS0yIGhvdXJzIG9mIGludGVu c2UgDQo+PiB1c2UsIHN3aXRjaGVzIG9mZi4NCj4+DQo+PiBJIGFtIHRoaW5raW5nIHRoZSBw b3dlciAod2UgY2FsbCBpdCAiYWxpbWVudGF0b3JlIiBidXQgDQo+PiBkdW5ubyB0aGUgRW5n bGlzaCB3b3JkIC4uLiB0aGUgcG93ZXIgc291cmNlLCBsZXQncyBzYXkpIGlzIA0KPj4gaW5z dWZmaWNpZW50IHRvIGNvdmVyIHVwIGFsbCBkZXZpY2VzIHByb3Blcmx5IGFuZCBmYWlscyB0 byANCj4+IHNlbmQgZW5vdWdoIGN1cnJlbnQgdG8gZXh0ZXJuYWwgZGV2aWNlcyAodGhlIEhE RCBiZWhhdmVzIA0KPj4gbm9ybWFsbHkpDQo+Pg0KPj4gbm93IHRoZSB0cnVlIHF1ZXN0aW9u IChUaGUgZHJpdmUgY3VycmVudGx5IGlzIG1vdW50ZWQgdmlhIA0KPj4gRlNUQUIpDQo+Pg0K Pj4gd291bGQgdW5tb3VudCB0aGUgZHJpdmUgY2F1c2UgaXQgdG8gc3RvcCBzcGlubmluZyA/ DQo+IA0KPiBOb3QgaW5tZWRpYXRlbHksIHRoZXJlIGlzIGEgdGltZW91dC4NCj4gDQo+ICDC oMKgwqDCoMKgwqAgaGRwYXJtIC0gZ2V0L3NldCBTQVRBL0lERSBkZXZpY2UgcGFyYW1ldGVy cw0KPiANCj4gIMKgwqDCoMKgwqDCoCAtQ8KgwqDCoMKgIENoZWNrIHRoZSBjdXJyZW50IElE RSBwb3dlciBtb2RlIHN0YXR1cywgDQo+IHdoaWNoIHdpbGwNCj4gIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIGFsd2F5c8KgIGJlwqAgb25lwqAgb2YgdW5rbm93biAoZHJpdmUgZG9l cyBub3QgDQo+IHN1cHBvcnQNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoaXPC oCBjb21tYW5kKSzCoCBhY3RpdmUvaWRsZcKgIChub3JtYWwgICANCj4gb3BlcmF0aW9uKSwN Cj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHN0YW5kYnnCoCAobG93wqAgcG93ZXIg bW9kZSwgZHJpdmUgaGFzIHNwdW4gDQo+IGRvd24pLCBvcg0KPiAgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgc2xlZXBpbmcgKGxvd2VzdCBwb3dlciBtb2RlLMKgIGRyaXZlwqAgaXMg IA0KPiBjb21wbGV0ZWx5DQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzaHV0wqAg ZG93bikuwqAgVGhlIC1TLCAteSwgLVksIGFuZCAtWiBvcHRpb25zIA0KPiBjYW4gYmUNCj4g IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVzZWQgdG8gbWFuaXB1bGF0ZSB0aGUgSURF IHBvd2VyIG1vZGVzLg0KPiANCj4gIMKgwqDCoMKgwqDCoCAtc8KgwqDCoMKgIEVuYWJsZS9k aXNhYmxlIHRoZSBwb3dlci1vbiBpbiBzdGFuZGJ5IA0KPiBmZWF0dXJlLMKgIGlmDQo+ICDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdXBwb3J0ZWTCoCBiecKgIHRoZcKgIGRyaXZl LsKgIFZFUlkgREFOR0VST1VTLiAgDQo+IERvIG5vdA0KPiAgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgdXNlIHVubGVzcyB5b3UgYXJlIGFic29sdXRlbHkgY2VydGFpbiB0aGF0IA0K PiBib3RoIHRoZQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc3lzdGVtwqAgQklP UyAob3IgZmlybXdhcmUpIGFuZCB0aGUgb3BlcmF0aW5nIA0KPiBzeXN0ZW0NCj4gIMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGtlcm5lbCAoTGludXggPj0gMi42LjIyKSBzdXBwb3J0 IHByb2JpbmcgZm9yIA0KPiBkcml2ZXMNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHRoYXTCoCB1c2UgdGhpcyBmZWF0dXJlLsKgIFdoZW4gZW5hYmxlZCwgdGhlIA0KPiBkcml2 ZSBpcw0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcG93ZXJlZC11cCBpbiB0aGUg c3RhbmRieSBtb2RlIHRvwqAgYWxsb3cgIA0KPiB0aGXCoCBjb24tDQo+ICDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB0cm9sbGVywqAgdG8gc2VxdWVuY2UgdGhlIHNwaW4tdXAgb2Yg ZGV2aWNlcywgDQo+IHJlZHVjLQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaW5n IHRoZSBpbnN0YW50YW5lb3VzIGN1cnJlbnQgZHJhdyBidXJkZW4gDQo+IHdoZW4gbWFueQ0K PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZHJpdmVzwqAgc2hhcmUgYSBwb3dlciBz dXBwbHkuwqAgUHJpbWFyaWx5IGZvciANCj4gdXNlIGluDQo+ICDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBsYXJnZSBSQUlEIHNldHVwcy7CoCBUaGlzIGZlYXR1cmXCoCBpcyAgDQo+ IHVzdWFsbHnCoCBkaXMtDQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhYmxlZMKg IGFuZMKgIHRoZcKgIGRyaXZlwqAgaXMgcG93ZXJlZC11cCBpbiB0aGUgDQo+IGFjdGl2ZQ0K PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbW9kZSAoc2VlIC1DIGFib3ZlKS7CoCBO b3RlIHRoYXQgYcKgIGRyaXZlICANCj4gbWF5wqAgYWxzbw0KPiAgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgYWxsb3cgZW5hYmxpbmcgdGhpcyBmZWF0dXJlIGJ5IGEganVtcGVyLiAg DQo+IFNvbWUgU0FUQQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZHJpdmVzIHN1 cHBvcnQgdGhlIGNvbnRyb2wgb2YgdGhpcyBmZWF0dXJlICANCj4gYnnCoCBwaW4NCj4gIMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDExwqAgb2bCoCB0aGXCoCBTQVRBwqAgcG93ZXIg Y29ubmVjdG9yLiBJbiB0aGVzZSANCj4gY2FzZXMsDQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB0aGlzIGNvbW1hbmQgbWF5IGJlIHVuc3VwcG9ydGVkIG9yIG1heSBoYXZlIA0K PiBub8KgIGVmLQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZmVjdC4NCj4gDQo+ ICDCoMKgwqDCoMKgwqAgLVPCoMKgwqDCoCBQdXTCoCB0aGUgZHJpdmUgaW50byBpZGxlIChs b3ctcG93ZXIpIG1vZGUsIA0KPiBhbmQgYWxzbw0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgc2V0IHRoZSBzdGFuZGJ5IChzcGluZG93bikgdGltZW91dCBmb3LCoCB0aGUgIA0K PiBkcml2ZS4NCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRoaXPCoCB0aW1lb3V0 wqAgdmFsdWUgaXMgdXNlZCBieSB0aGUgZHJpdmUgdG8gDQo+IGRldGVyLQ0KPiAgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgbWluZSBob3cgbG9uZyB0byB3YWl0ICh3aXRoIG5vIGRp c2sgIA0KPiBhY3Rpdml0eSnCoCBiZS0NCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGZvcmXCoCB0dXJuaW5nwqAgb2ZmIHRoZSBzcGluZGxlIG1vdG9yIHRvIHNhdmUgDQo+IHBv d2VyLg0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVW5kZXIgc3VjaCBjaXJjdW1z dGFuY2VzLCB0aGXCoCBkcml2ZcKgIG1heSAgDQo+IHRha2XCoCBhcw0KPiAgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgbG9uZ8KgIGFzIDMwIHNlY29uZHMgdG8gcmVzcG9uZCB0byBh IA0KPiBzdWJzZXF1ZW50IGRpc2sNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGFj Y2VzcywgdGhvdWdoIG1vc3QgZHJpdmVzIGFyZSBtdWNoICANCj4gcXVpY2tlci7CoMKgIFRo ZQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZW5jb2Rpbmcgb2YgdGhlIHRpbWVv dXQgdmFsdWUgaXMgc29tZXdoYXQgDQo+IHBlY3VsaWFyLg0KPiAgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgQSB2YWx1ZSBvZiB6ZXJvIG1lYW5zICJ0aW1lb3V0cyBhcmUgDQo+IGRp c2FibGVkIjrCoCB0aGUNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRldmljZcKg IHdpbGzCoCBub3QgYXV0b21hdGljYWxseSBlbnRlciBzdGFuZGJ5IA0KPiBtb2RlLg0KPiAg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVmFsdWVzIGZyb20gMSB0byAyNDAgc3BlY2lm eSBtdWx0aXBsZXPCoCBvZiAgDQo+IDXCoCBzZWMtDQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBvbmRzLMKgIHlpZWxkaW5nwqAgdGltZW91dHMgZnJvbSA1IHNlY29uZHMgdG8g DQo+IDIwIG1pbi0NCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHV0ZXMuwqAgVmFs dWVzIGZyb20gMjQxIHRvIDI1MSBzcGVjaWZ5IGZyb20gMSANCj4gdG/CoCAxMQ0KPiAgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdW5pdHMgb2YgMzAgbWludXRlcywgeWllbGRpbmcg dGltZW91dHMgZnJvbSANCj4gMzAgbWluLQ0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgdXRlcyB0byA1LjUgaG91cnMuwqAgQcKgIHZhbHVlwqAgb2bCoCAyNTIgIA0KPiBzaWdu aWZpZXPCoCBhDQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aW1lb3V0wqAgb2bC oCAyMSBtaW51dGVzLiBBIHZhbHVlIG9mIDI1MyBzZXRzIA0KPiBhIHZlbi0NCj4gIMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRvci1kZWZpbmVkIHRpbWVvdXQgcGVyaW9kIGJldHdl ZW4gOCBhbmQgMTIgIA0KPiBob3VycywNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGFuZMKgIHRoZSB2YWx1ZSAyNTQgaXMgcmVzZXJ2ZWQuwqAgMjU1IGlzIA0KPiBpbnRlcnBy ZXRlZA0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXMgMjEgbWludXRlcyBwbHVz wqAgMTXCoCBzZWNvbmRzLsKgwqAgTm90ZSAgDQo+IHRoYXTCoCBzb21lDQo+ICDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBvbGRlcsKgIGRyaXZlc8KgIG1hecKgIGhhdmUgdmVyeSBk aWZmZXJlbnQgDQo+IGludGVycHJldGEtDQo+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB0aW9ucyBvZiB0aGVzZSB2YWx1ZXMuDQo+IA0KPiANCj4+DQo+PiBUaGVyZSBpcyBhIGZh c3RlciB3YXkgdG8gc2VuZG8gc29tZSBsb3cgbGV2ZWwgY29tbWFuZCB0byANCj4+IG1ha2Ug aXQgc3RvcCBzcGlubmluZyA/IEkuZy4gc29tZSAiSU9DVEwiIHNlcXVlbmNlLg0KPiANCj4g VGhlICItUyIgb3B0aW9uIGFib3ZlLg0KPiANCj4gDQo+PiBmb3IgdGhvc2UgcmVhbGx5IGtu b3dsZWRnZWFibGUgaW4gaW50ZXJuYWwgTGludXggd29ya2luZyA6IA0KPj4gZG9lcyBhIGRy aXZlIG5vdCBhY3RpdmVseSB1c2VkIChubyBmaWxlcyBvcGVuZWQsIG5vIGZpbGUgDQo+PiBt YW5hZ2VyIG9wZXJhdGluZyBvbiBpdCkgcmVxdWlyZSBzb21lIGZvcm0gb2YgInBvbGxpbmci IA0KPj4gaXRzIHN0YXRlIHRoYXQgd291bGQgY2F1c2UgZnJlcXVlbnQgYXV0b21hdGljYWwg cmVzdGFydGlnIA0KPj4gb2Ygc3Bpbm5pbmcgPyBJbiB0aGlzIGNhc2UsIHN0b3BwaW5nIGl0 IHdvdWxkIGJlIGhhcm1mdWwgDQo+PiBhbmQgZW5oYW5jZSBwcmVhdHVyZSB3ZWFyaW5nIG9m IHRoZSBtb3RvcnMgYW5kIGFsbCBhbmQgaXQgDQo+PiB3b3VsZCBoYXZlIG5vIGJlbmVmaXQg dG8gbWFudWFsbHkgc3RvcCBzcGlubmluZy4NCj4gDQo+IFRoZXJlIGNhbiBiZSBvcGVyYXRp b25zIHRoYXQgdHJpZ2dlciBwZXJpb2RpY2FsbHkgdGhhdCB3b3VsZCANCj4gY2F1c2UgdGhl IGRpc2sgdG8gc3BpbiB1cCBhZ2Fpbi4gVHlwaWNhbCBjdWxwcml0cyB3ZXJlIA0KPiBzeXNs b2cuIEkgc2VlbSB0byByZW1lbWJlciBzb21lIDcgbWludXRlcyB0aW1lb3V0IHNvbWV3aGVy ZSwgDQo+IGp1c3QgYSBmb2dneSBtZW1vcnkuDQo+IA0KPiBJZiB0aGUgZGlzayBpcyB1bW91 bnRlZCwgdGhlbiBoYXJkbHkuIFdlbGwsIGEgY29tbWFuZCBzdWNoIA0KPiBhcyAibHNibGsi IGNvdWxkIHdha2UgdXAgYWxsIGRpc2tzLCBiZWNhdXNlIGl0IHByb2JlcyB0aGVtIA0KPiBh bGwuIFNtYXJ0Y3RsLi4uIEkgdGhpbmsgdGhlcmUgaXMgYW4gb3B0aW9uIHRlbGxpbmcgaXQg dG8gDQo+IHdha2Ugb3Igbm90IHdha2UgYSBzbGVlcGluZyBkaXNrLg0KPiANCg0KdG54ICEN Cg0KLS0gDQoxKSBSZXNpc3RlcmUsIHJlc2lzdGVyZSwgcmVzaXN0ZXJlLg0KMikgU2UgdHV0 dGkgcGFnYW5vIGxlIHRhc3NlLCBsZSB0YXNzZSBsZSBwYWdhbm8gdHV0dGkNCk1hcmlvQ1BQ UA0KDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)