Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: shadowrn@*********.com (Kesh)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 13:20:04 2001
On Mon, 19 Mar 2001 09:46:39 -0500, Michael Yacht wrote:

>> Is off-line storage able to be wiped by Tar IC?
>>
>> -Boondocker
>
>No, that is the whole point of Offline.
>
>I'll go one step further, I'm 99% sure that you can't download directly into
>Offline storage either.
>
>My understanding of the storage types and their modern day equivalents:
>
>Online == Harddrive
>Active == RAM
>Offline == Burned CDs
>
>
>-Nog

Actually, my understanding is that it's more like an external hard drive,
with some differences. You used to be right, Nog, because I think in SR2
you couldn't load utilities directly from Offline storage nor download
directly to it. But now, on page 216 of SR3, the Download Data operation
says you *can* download directly to offline storage, and there is nothing
in the Matrix section which says you cannot load utilities from it. So,
if this hasn't been changed in the Matrix book, I'd say that Tar *could*
go after files on Offline storage, so long as that storage is actually
plugged into the deck (ie. it can't touch Offline storage that's truely
off-line and unplugged).

In the old edition, you couldn't download straight to the Offline
storage, but no real reason was given why. Since it runs over an external
connection, it apparently can't keep up with data coming straight from
the Matrix, so any downloads must go to the Online storage first (hard
drive), then be copied to the Offline (external) storage. The best
analogy I can think of would be a 'buffer overrun' that sometimes happens
with CD burners, where the data is being sent to the drive faster than it
can write to the disc.

Same with loading programs into Active memory... it has to be copied from
the slower Offline storage to the Online, which will be fast enough to
load it properly. I would guess this is analagous to 'buffer underrun',
where the data can't be uploaded as fast as the Active memory needs it to
run the program. I don't know *why* this is the case, unless the on-board
bus is just that much faster than the external connection that Offline
storage can't keep up with it.

My best guess as to why they changed this is that you *can* do downloads
directly to external devices in modern machines, so why would future
devices be less useful? That's the only reason I can think of why they
allow it now.
Message no. 2
From: shadowrn@*********.com (Michael Yacht)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 13:35:01 2001
> Actually, my understanding is that it's more like an external hard drive,
> with some differences. You used to be right, Nog, because I think in SR2
> you couldn't load utilities directly from Offline storage nor download
> directly to it. But now, on page 216 of SR3, the Download Data operation
> says you *can* download directly to offline storage, and there is nothing
> in the Matrix section which says you cannot load utilities from it. So,
> if this hasn't been changed in the Matrix book, I'd say that Tar *could*
> go after files on Offline storage, so long as that storage is actually
> plugged into the deck (ie. it can't touch Offline storage that's truely
> off-line and unplugged).
>
> In the old edition, you couldn't download straight to the Offline
> storage, but no real reason was given why. Since it runs over an external
> connection, it apparently can't keep up with data coming straight from
> the Matrix, so any downloads must go to the Online storage first (hard
> drive), then be copied to the Offline (external) storage. The best
> analogy I can think of would be a 'buffer overrun' that sometimes happens
> with CD burners, where the data is being sent to the drive faster than it
> can write to the disc.
>
> Same with loading programs into Active memory... it has to be copied from
> the slower Offline storage to the Online, which will be fast enough to
> load it properly. I would guess this is analagous to 'buffer underrun',
> where the data can't be uploaded as fast as the Active memory needs it to
> run the program. I don't know *why* this is the case, unless the on-board
> bus is just that much faster than the external connection that Offline
> storage can't keep up with it.
>
> My best guess as to why they changed this is that you *can* do downloads
> directly to external devices in modern machines, so why would future
> devices be less useful? That's the only reason I can think of why they
> allow it now.

Ok, if that is the case, and everything you said is true .. what is the
logistical differences? If I can load programs from offline .. then is it
offline? No, it is online. There has to be a difference between the two to
justify having the category and the cost difference. Frankly, I think it is
silly that there are 3 categories at all. Should all just be online, active
and storage (Burned CDs, backups, whatever) on optical chips or somesuch.
Offline never made much sense to me.

-Nog
Message no. 3
From: shadowrn@*********.com (Michael Webb)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 13:45:01 2001
I would have to agree with the last sentiment posted. Offline storage to me
has to represent cheap storage, not accessible to somebody running around on
the matrix. The most logical presumption would be that whatever its stored
on isn't directly connected to his deck, and/or isn't high speed enough to
be downloaded to the matrix.

Just because they don't specify that it can't be used, doesn't mean it's all
the same. That's the kind of oversight that game designers make all the
time. They left us to make an assumption, and in my games I assume you can't
use it. (Otherwise, what's the difference?)

-----Original Message-----
From: shadowrn-admin@*********.com
[mailto:shadowrn-admin@*********.com]On Behalf Of Michael Yacht
Sent: Monday, March 19, 2001 11:37 AM
To: shadowrn@*********.com
Subject: Re: Offline Storage (was Re: So you STILL want to be a Decker.)


> Actually, my understanding is that it's more like an external hard drive,
> with some differences. You used to be right, Nog, because I think in SR2
> you couldn't load utilities directly from Offline storage nor download
> directly to it. But now, on page 216 of SR3, the Download Data operation
> says you *can* download directly to offline storage, and there is nothing
> in the Matrix section which says you cannot load utilities from it. So,
> if this hasn't been changed in the Matrix book, I'd say that Tar *could*
> go after files on Offline storage, so long as that storage is actually
> plugged into the deck (ie. it can't touch Offline storage that's truely
> off-line and unplugged).
>
> In the old edition, you couldn't download straight to the Offline
> storage, but no real reason was given why. Since it runs over an external
> connection, it apparently can't keep up with data coming straight from
> the Matrix, so any downloads must go to the Online storage first (hard
> drive), then be copied to the Offline (external) storage. The best
> analogy I can think of would be a 'buffer overrun' that sometimes happens
> with CD burners, where the data is being sent to the drive faster than it
> can write to the disc.
>
> Same with loading programs into Active memory... it has to be copied from
> the slower Offline storage to the Online, which will be fast enough to
> load it properly. I would guess this is analagous to 'buffer underrun',
> where the data can't be uploaded as fast as the Active memory needs it to
> run the program. I don't know *why* this is the case, unless the on-board
> bus is just that much faster than the external connection that Offline
> storage can't keep up with it.
>
> My best guess as to why they changed this is that you *can* do downloads
> directly to external devices in modern machines, so why would future
> devices be less useful? That's the only reason I can think of why they
> allow it now.

Ok, if that is the case, and everything you said is true .. what is the
logistical differences? If I can load programs from offline .. then is it
offline? No, it is online. There has to be a difference between the two to
justify having the category and the cost difference. Frankly, I think it is
silly that there are 3 categories at all. Should all just be online, active
and storage (Burned CDs, backups, whatever) on optical chips or somesuch.
Offline never made much sense to me.

-Nog
Message no. 4
From: shadowrn@*********.com (Jonathan Choy)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 16:00:01 2001
----- Original Message -----
From: "Kesh" <kesh@***.com>
To: "ShadowRN" <shadowrn@*********.com>
Sent: 19 March 2001 1:15 PM
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)


> On Mon, 19 Mar 2001 09:46:39 -0500, Michael Yacht wrote:
>
> >> Is off-line storage able to be wiped by Tar IC?
> >>
> >> -Boondocker
> >
> >No, that is the whole point of Offline.
> >
> >I'll go one step further, I'm 99% sure that you can't download directly
into
> >Offline storage either.
Start | Run | http://plastic.dumpshock.com | right click link. Pick save
target as. Browse to your A drive with a floppy in it. Downloads to either
Active or Online and automatically copies to offline. (depends on
configuration and file size - usually Online)
> >
> >My understanding of the storage types and their modern day equivalents:
> >
> >Online == Harddrive
> >Active == RAM
> >Offline == Burned CDs
Floppies are a fine example of Offline. So are CDRWs using things like
DirectCD. Both can be written to as online storage without using a separate
burn step (cf. CDRs)
<snip stuff about differences between VR2 and Matrix rules>

> in the Matrix section which says you cannot load utilities from it. So,
> if this hasn't been changed in the Matrix book, I'd say that Tar *could*
> go after files on Offline storage, so long as that storage is actually
> plugged into the deck (ie. it can't touch Offline storage that's truely
> off-line and unplugged).
Looking at it from the standpoint of the aging Win32 platform, Tar could
kill stuff in Active. It could corrupt the copy in Online. It can kill
Offline if the media is attached to Offline - Offline is 90%+ a removable
medium now, and will probably be the same in 2060.

>
> In the old edition, you couldn't download straight to the Offline
> storage, but no real reason was given why. Since it runs over an external
> connection, it apparently can't keep up with data coming straight from
> the Matrix, so any downloads must go to the Online storage first (hard
> drive), then be copied to the Offline (external) storage. The best
> analogy I can think of would be a 'buffer overrun' that sometimes happens
> with CD burners, where the data is being sent to the drive faster than it
> can write to the disc.
This is a buffer underrun condition normally, actually. Not enough data is
sent to the drive and it ends up writing garbage when it gets to the end of
what you've supplied.

More appropriate for a situation where you are going into this much detail
in your Matrix work (which I used to think was a requirement, and have since
decided is too damn much work (you might remember I was starting to work on
Matrix rules that didn't make me want to puke. real life has interfered and
I've decided to just ignore things and let the same abstractions that reduce
a martial arts combat into a set of success tests reduce computer intrusion
into black magic in much the same fashion)) is that you instead do a little
work and create a few more things to eat up that decker's money. There are
many types of offline or 'nearline'(don't ask if you don't know - it's a
distinction that would make the matrix rules even cuter... short version is
that it's REALLY SLOW online storage) storage devices available now - things
should get more interesting in the next 59 years, not less...

Diagram of storage types, from fastest to slowest
Active Memory - RAM. SDRAM, RIMM, DDS SDRAM, etc.
Paged Memory - Swapped out memory - use storage 'like' Active memory. Solid
State Storage is good for this hybrid between Active memory and Online
Storage
Online Storage - data which survives your computer crashing (barring the
computer corrupting the data on it, or a physical problem with the medium) -
if it would survive rebooting the deck, it's here or lower.
Active ROM - your MPCP, among other things, would fall into this category.
If you can't replace it without burning new chips, you can't have it harmed
without the computer physically going up in smoke. I won't argue that this
can't happen, since you can do it to certain PDPs, and the Apple II. Faster
than Online Storage, slower than Active Memory, and doesn't matter for the
most part since once you're booted it's (possibly - depends on how the
operating system and hardware interact in a deck... but let's not go there)
not doing much read/write from it.
Nearline storage - for a large facility, this can be the most important part
of the system. A tape robot silo is 'nearline' storage, or a multi-disc
CDROM reader. Anything where your computer can fetch the right media for
you, but it might take several minutes to unmount and remount the device,
depending on the size of the Nearline store. Note that current systems for
tape robots can have capacities in the multi-terabyte or higher range, and
price tags start in the high 6 digits and go up-up-UP! A CDRW running
DirectCD is another potential mixed Nearline / Offline device - special
cases are FUN aren't they?

Offline storage - storage that cannot be affected by your deck melting. This
can be anything from a CDR in a read-only drive, to a tape backup with the
tape ejected from the drive, to a multi-terabyte stack of digital linear
tape in an abandoned salt mine in Utah.

Modern DAT DDS-4 drives connect to the Ultra/160 SCSI bus just fine. Dell
ships their ATA-based servers (when you add on a SCSI backup device - OT
this is a DAMN GOOD IDEA... in case anyone should happen to zip around and
ask you) with a 39160 controller and a DDS-4 drive that has NO PRAYER IN
HELL of keeping up with the 160MB/s throughput the controller's data channel
can pump. Doesn't matter - even a broken OS like Win9X can buffer writes in
memory such that the tape drive gets data at the appropriate speed
(configuration might be required, but your decker should be better at
configuring such things in game than I am in real life. Or you need a better
decker...) The limiting factor here is the write speed of the tape
mechanism. Similar issues exist with CD rewriters - the software uses active
memory to buffer the write to account for the write speed of the device.
Using the appropriate software, a decker could use a mixture of Active and
Online storage to make an Offline copy happen automatically as the data
shows up - you would have to assign I/O characteristics to the devices to
decide what the speeds are.

Other possibilities include a Network Attached Storage system - where you
have a network of hosts of your own that the deck writes to, but needs a
different privilege level to delete from... makes it awfully hard for that
black IC to kill your download... it can trash things after it gets your
deck, but only if it has the ability to hack YOUR network.... which is not a
normal IC procedure last time I looked.

>
> Same with loading programs into Active memory... it has to be copied from
> the slower Offline storage to the Online, which will be fast enough to
> load it properly. I would guess this is analagous to 'buffer underrun',
> where the data can't be uploaded as fast as the Active memory needs it to
> run the program. I don't know *why* this is the case, unless the on-board
> bus is just that much faster than the external connection that Offline
> storage can't keep up with it.

This is a load of crap. CF running (statically linked/small) programs from
floppy disks.

>
> My best guess as to why they changed this is that you *can* do downloads
> directly to external devices in modern machines, so why would future
> devices be less useful? That's the only reason I can think of why they
> allow it now.

Because someone smacked around the writers who were ignoring things that
could be done before SR1 came out. CF downloading things with a commodore 64
onto a diskette in your 1541. Offline storage? sure. Fast? no...

Tetsujin no Oni
Soapboxy shadowlands technology guy - Shadowlands Dueling Sensei
"Of course I fight dirty... I'm from the Horde!"
Message no. 5
From: shadowrn@*********.com (Michael Webb)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 17:10:01 2001
While I appreciate the examples, there are instances of this reply where I
don't really understand where your going with it.

One thing I'd like to point out is that this is the matrix, not world wide
web retrieval. Supposedly a lot of these actions are taking up a hundredth
of a second or less, and actions like saving to a floppy/cd or anything
else, which does in fact take longer, would take a very long, long time, and
would probably get you noticed.

I don't like a lot of the matrix rules myself, but they are the best we've
got. I would like something a bit more realistic, but your throwing so much
detail from real life that your clouding the issue. There does need to be
something of a blend between realism and playability.

If your going to respond in this way, you might want to come up with an
example of the rules you are talking about, which would be realistic but
playable.

> On Mon, 19 Mar 2001 09:46:39 -0500, Michael Yacht wrote:
>
> >> Is off-line storage able to be wiped by Tar IC?
> >>
> >> -Boondocker
> >
> >No, that is the whole point of Offline.
> >
> >I'll go one step further, I'm 99% sure that you can't download directly
into
> >Offline storage either.
-Start | Run | http://plastic.dumpshock.com | right click link. Pick save
-target as. Browse to your A drive with a floppy in it. Downloads to either
-Active or Online and automatically copies to offline. (depends on
-configuration and file size - usually Online)

> >
> >My understanding of the storage types and their modern day equivalents:
> >
> >Online == Harddrive
> >Active == RAM
> >Offline == Burned CDs
Floppies are a fine example of Offline. So are CDRWs using things like
DirectCD. Both can be written to as online storage without using a separate
burn step (cf. CDRs)
<snip stuff about differences between VR2 and Matrix rules>

> in the Matrix section which says you cannot load utilities from it. So,
> if this hasn't been changed in the Matrix book, I'd say that Tar *could*
> go after files on Offline storage, so long as that storage is actually
> plugged into the deck (ie. it can't touch Offline storage that's truely
> off-line and unplugged).
Looking at it from the standpoint of the aging Win32 platform, Tar could
kill stuff in Active. It could corrupt the copy in Online. It can kill
Offline if the media is attached to Offline - Offline is 90%+ a removable
medium now, and will probably be the same in 2060.

>
> In the old edition, you couldn't download straight to the Offline
> storage, but no real reason was given why. Since it runs over an external
> connection, it apparently can't keep up with data coming straight from
> the Matrix, so any downloads must go to the Online storage first (hard
> drive), then be copied to the Offline (external) storage. The best
> analogy I can think of would be a 'buffer overrun' that sometimes happens
> with CD burners, where the data is being sent to the drive faster than it
> can write to the disc.
This is a buffer underrun condition normally, actually. Not enough data is
sent to the drive and it ends up writing garbage when it gets to the end of
what you've supplied.

More appropriate for a situation where you are going into this much detail
in your Matrix work (which I used to think was a requirement, and have since
decided is too damn much work (you might remember I was starting to work on
Matrix rules that didn't make me want to puke. real life has interfered and
I've decided to just ignore things and let the same abstractions that reduce
a martial arts combat into a set of success tests reduce computer intrusion
into black magic in much the same fashion)) is that you instead do a little
work and create a few more things to eat up that decker's money. There are
many types of offline or 'nearline'(don't ask if you don't know - it's a
distinction that would make the matrix rules even cuter... short version is
that it's REALLY SLOW online storage) storage devices available now - things
should get more interesting in the next 59 years, not less...

Diagram of storage types, from fastest to slowest
Active Memory - RAM. SDRAM, RIMM, DDS SDRAM, etc.
Paged Memory - Swapped out memory - use storage 'like' Active memory. Solid
State Storage is good for this hybrid between Active memory and Online
Storage
Online Storage - data which survives your computer crashing (barring the
computer corrupting the data on it, or a physical problem with the medium) -
if it would survive rebooting the deck, it's here or lower.
Active ROM - your MPCP, among other things, would fall into this category.
If you can't replace it without burning new chips, you can't have it harmed
without the computer physically going up in smoke. I won't argue that this
can't happen, since you can do it to certain PDPs, and the Apple II. Faster
than Online Storage, slower than Active Memory, and doesn't matter for the
most part since once you're booted it's (possibly - depends on how the
operating system and hardware interact in a deck... but let's not go there)
not doing much read/write from it.
Nearline storage - for a large facility, this can be the most important part
of the system. A tape robot silo is 'nearline' storage, or a multi-disc
CDROM reader. Anything where your computer can fetch the right media for
you, but it might take several minutes to unmount and remount the device,
depending on the size of the Nearline store. Note that current systems for
tape robots can have capacities in the multi-terabyte or higher range, and
price tags start in the high 6 digits and go up-up-UP! A CDRW running
DirectCD is another potential mixed Nearline / Offline device - special
cases are FUN aren't they?

Offline storage - storage that cannot be affected by your deck melting. This
can be anything from a CDR in a read-only drive, to a tape backup with the
tape ejected from the drive, to a multi-terabyte stack of digital linear
tape in an abandoned salt mine in Utah.

Modern DAT DDS-4 drives connect to the Ultra/160 SCSI bus just fine. Dell
ships their ATA-based servers (when you add on a SCSI backup device - OT
this is a DAMN GOOD IDEA... in case anyone should happen to zip around and
ask you) with a 39160 controller and a DDS-4 drive that has NO PRAYER IN
HELL of keeping up with the 160MB/s throughput the controller's data channel
can pump. Doesn't matter - even a broken OS like Win9X can buffer writes in
memory such that the tape drive gets data at the appropriate speed
(configuration might be required, but your decker should be better at
configuring such things in game than I am in real life. Or you need a better
decker...) The limiting factor here is the write speed of the tape
mechanism. Similar issues exist with CD rewriters - the software uses active
memory to buffer the write to account for the write speed of the device.
Using the appropriate software, a decker could use a mixture of Active and
Online storage to make an Offline copy happen automatically as the data
shows up - you would have to assign I/O characteristics to the devices to
decide what the speeds are.

Other possibilities include a Network Attached Storage system - where you
have a network of hosts of your own that the deck writes to, but needs a
different privilege level to delete from... makes it awfully hard for that
black IC to kill your download... it can trash things after it gets your
deck, but only if it has the ability to hack YOUR network.... which is not a
normal IC procedure last time I looked.

>
> Same with loading programs into Active memory... it has to be copied from
> the slower Offline storage to the Online, which will be fast enough to
> load it properly. I would guess this is analagous to 'buffer underrun',
> where the data can't be uploaded as fast as the Active memory needs it to
> run the program. I don't know *why* this is the case, unless the on-board
> bus is just that much faster than the external connection that Offline
> storage can't keep up with it.

_This is a load of crap. CF running (statically linked/small) programs from
_floppy disks.

Um, what are you saying? I can run stuff from floppy disk, but it is
painfully slow...

>
> My best guess as to why they changed this is that you *can* do downloads
> directly to external devices in modern machines, so why would future
> devices be less useful? That's the only reason I can think of why they
> allow it now.

Because someone smacked around the writers who were ignoring things that
could be done before SR1 came out. CF downloading things with a commodore 64
onto a diskette in your 1541. Offline storage? sure. Fast? no...

Tetsujin no Oni
Soapboxy shadowlands technology guy - Shadowlands Dueling Sensei
"Of course I fight dirty... I'm from the Horde!"
Message no. 6
From: shadowrn@*********.com (Kesh)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 18:55:00 2001
On Mon, 19 Mar 2001 13:36:44 -0500, Michael Yacht wrote:


>Ok, if that is the case, and everything you said is true .. what is the
>logistical differences? If I can load programs from offline .. then is it
>offline? No, it is online. There has to be a difference between the two to
>justify having the category and the cost difference. Frankly, I think it is
>silly that there are 3 categories at all. Should all just be online, active
>and storage (Burned CDs, backups, whatever) on optical chips or somesuch.
>Offline never made much sense to me.
>
>-Nog

Yea, Offline doesn't make much sense. The only reason I can think of for
the cost difference is that perhaps it doesn't have to be made small
enough to fit inside a deck, so it's cheaper to manufacture (ie. the
difference between a slim hard drive for a laptop and a larger one for
towers or external use). Kind of a stretch, but the only reason I can
think of for it.

As for Online/Offline, Online storage is built into the deck and cannot
be turned off unless the whole deck is. Offline storage can be plugged
in/removed while the deck is running, just like a USB hard drive. Still a
pretty silly thing, but *shrug*.
Message no. 7
From: shadowrn@*********.com (Kesh)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 18:55:03 2001
On Mon, 19 Mar 2001 14:49:06 -0500, Jonathan Choy wrote:

>> in the Matrix section which says you cannot load utilities from it. So,
>> if this hasn't been changed in the Matrix book, I'd say that Tar *could*
>> go after files on Offline storage, so long as that storage is actually
>> plugged into the deck (ie. it can't touch Offline storage that's truely
>> off-line and unplugged).
>Looking at it from the standpoint of the aging Win32 platform, Tar could
>kill stuff in Active. It could corrupt the copy in Online. It can kill
>Offline if the media is attached to Offline - Offline is 90%+ a removable
>medium now, and will probably be the same in 2060.

Right. That's exactly what I said.

>> In the old edition, you couldn't download straight to the Offline
>> storage, but no real reason was given why. Since it runs over an external
>> connection, it apparently can't keep up with data coming straight from
>> the Matrix, so any downloads must go to the Online storage first (hard
>> drive), then be copied to the Offline (external) storage. The best
>> analogy I can think of would be a 'buffer overrun' that sometimes happens
>> with CD burners, where the data is being sent to the drive faster than it
>> can write to the disc.
>This is a buffer underrun condition normally, actually. Not enough data is
>sent to the drive and it ends up writing garbage when it gets to the end of
>what you've supplied.

Er, that's the exact opposite of what I just described. I was talking
about *too much* data going to the drive, rather than not enough.

[snipped a lot of involved analysis of various deck components]

>Offline storage - storage that cannot be affected by your deck melting. This
>can be anything from a CDR in a read-only drive, to a tape backup with the
>tape ejected from the drive, to a multi-terabyte stack of digital linear
>tape in an abandoned salt mine in Utah.

Eh, external disk drives would also fall into that category. And
actually, I disagree with the whole idea of it being just removable drive
storage. The way I read it, you're buying one block of storage (ie 1000
MPs or such), rather than multiple small ones that can be swapped in and
out (ie. 10 x 100 Mps). Of course, you could do the latter, but that
sounds like a lot of trouble for some offline storage. I think my
external hard drive analogy still holds up.

[snipped a lot of discussion about tape drives]

>>
>> Same with loading programs into Active memory... it has to be copied from
>> the slower Offline storage to the Online, which will be fast enough to
>> load it properly. I would guess this is analagous to 'buffer underrun',
>> where the data can't be uploaded as fast as the Active memory needs it to
>> run the program. I don't know *why* this is the case, unless the on-board
>> bus is just that much faster than the external connection that Offline
>> storage can't keep up with it.
>
>This is a load of crap. CF running (statically linked/small) programs from
>floppy disks.

What? I wasn't saying this is how it should be, I'm saying this is how
the SR1&2 rules handled it. You're right, modern machines can run
directly off of other storage devices (excluding tape), so I'd say the
new SR3 rules make more sense.
Message no. 8
From: shadowrn@*********.com (Jonathan Choy)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Mon Mar 19 21:10:01 2001
> -----Original Message-----
> From: shadowrn-admin@*********.com
> [mailto:shadowrn-admin@*********.com]On Behalf Of Michael Webb
> Sent: Monday, March 19, 2001 5:12 PM
> To: shadowrn@*********.com
> Subject: RE: Offline Storage (was Re: So you STILL want to be a Decker.)
>
>
> While I appreciate the examples, there are instances of this reply where I
> don't really understand where your going with it.
>
> One thing I'd like to point out is that this is the matrix, not world wide
> web retrieval. Supposedly a lot of these actions are taking up a hundredth
Same difference ... transmit and save is still transmit and save, and a file
that is X (x>200) MP wide will still take a while to shove through a pipe
that is Y (y < 100) MP wide. Use sizes that make sense to you...
> of a second or less, and actions like saving to a floppy/cd or anything
> else, which does in fact take longer, would take a very long,
> long time, and
> would probably get you noticed.
The point about buffering in faster memory media remains my real point...

Okay, new diagram.

---
Matrix Host - Network Interface - Active Memory - Online Storage - Offline
Storage
---

You can store to any of them, but there are (read should be, add a stat and
a component to the deck) associated IO speeds between each layer.
The IO speed can be compensated for (read ignored) if you have enough memory
in the prior layer to hold all of the information you are storing. Simple
enough?

*goes and grabs Matrix*

Kicking around a few ideas, and looking at the fact that Matrix no longer
seems to have rules for I/O bandwidth limits beyond the jackpoint and/or
your deck. I find that the simplest way to rule this is that a swap memory
test can only be made with Online Storage, but you can write to either
Online or Offline storage if you have enough memory in the 'faster' or
'closer' storage type, at the player's choice. If the operation has finished
when the deck is attacked by IC or an Agent, I would give an extra test for
the MPCP to block access to Offline storage, if not automatically have the
IC or the agent fail to damage the information in the Offline storage -
because it would find no targets in the Online storage, and offline storage
is too variable in possible configuration to attack simply.

Short version: if your available active memory is more than you need to save
it, you can save it anywhere but will lose it if your deck crashes before
the operation finishes. If your online storage is sufficient to save it, you
can save it to online or offline, but again the file will be vulnerable
until you have completed the download.

Complex version:
Adding another set of IO Speed components to the Deck Construction
guidelines that gives you the following setup
Jackpoint Speed
Network IO (Old IO speed)
Memory Bandwidth (MPCP to Active memory bandwidth - this needs to be MUCH
higher than your Network IO, and should exceed the sum of all of the IO
scores)
*(ASIST Bandwidth) (how much MPCP juice does it take to do the heavy lifting
of drawing a realtime matrix?) (nah, let's skip that one for now)
Storage Bandwidth (Active Memory to Storage interface - determines load
times for Swap Memory operations)
FUP bandwidth - probably only comes in a few flavors - you then need to
assign bandwidth values to each of the peripherals on FUP ports.

(side note: Note that FUP == USB for all intents and purposes, but USB is a
trademark...)


Tetsujin no Oni
"Of course I fight dirty... I'm from the Horde!"
And yes, I'm a pedantic ass....
>
Message no. 9
From: shadowrn@*********.com (Wavy Davy)
Subject: Offline Storage (was Re: So you STILL want to be a Decker.)
Date: Tue Mar 20 05:20:00 2001
On Mon, 19 Mar 2001, Jonathan Choy wrote:

[snip informed discussion of various modern day storage mediums]


Isn't compareng todays different method of strage a little academic
given SR relience on optical storage? IRC, there are only two types of
storage media mentioned in SR, optical chip and CD, and even then CD is
only mentioned with regard to hermetic libraries. 1 CD = 100MP?

I reckon that FASA were dealing with 'playable' computer concepts that
work rules wise (obviously) and dramatically. By dramatically I mean that
in terms of playing a decker, having active and storage memory that you
have to swap and manage resource wise make for a playable system. In
reality, I suspect, deckers would have near limitless active/storage
memory (based on the current trends, and also that most 'utility' programs
in SR, in todays version, are quite small. The average virus is maybe
400 bytes long :)

Regards offline storage, again it's a playable concept. It makes
managing you various memories a challenge and provides some limitation
to keep deckers from being too powerful (as I reckon they proably would
be IRL). And in the playable concept of offline memory it kinda make
sense not to be able to write to it online, other wise its the same as
storage, just cheaper.

However the computing rules do suck :) They bear little resemblance to
current computing concepts, IMHO. But then thats part of the reason
why FASA introduced the '29 crash - in order to create a playable model
of computing different from our current one, plausably. Thats my theory,
anyway :)

I was working on some more realistic rules, but I stopped because I
realised the above, that the canon rules are playable (sort of :) and
work from a game mechanism point of view. Plus no one im my group would
be able to understand my rules, not being Comp Sci graduates :)


--
Wavy Davy (who shares wins)
...I think the mistake a lot of us make is thinking the state-appointed
psychiatrist is our "friend."

Further Reading

If you enjoyed reading about Offline Storage (was Re: So you STILL want to be a Decker.), you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.

Thwap!