Thanks Paul for the detailed clarification!
On 11.10.2013 17:23, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 2:28 AM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
...
Yes, that would be the one when converting between FDDI and 100BaseT Ethernet.
The best effort it can produce is about what 100BaseT can, because it is the lowest common nominator. FDDI performs better due to the larger packet size (which is usable only between FDDI nodes) and the lower overhead.
Larger packet size, yes. Lower overhead, no. Token systems of any kind are guaranteed to be less efficient than Ethernet, because you have to wait for the token. At best, they will be slightly better under very high load than half duplex Ethernet, but full duplex Ethernet will outperform any token network under all conditions.
It's very clear that FDDI will outperform half duplex Ethernet, because there will not occur any collisions in FDDI.
But if we think about a FDDI-to-100BaseT (Full duplex) topology and the traffic flows with as large packets as possible, doesn't FDDI be able to carry about three times more payload in each packet than Ethernet? In that case one FDDI packet payload will need to be split into three Ethernet packets and three Ethernet packet payloads will fit into one FDDI packet.
Btw. Many of the FDDI principles was used when developing FibreChannel.
Not really. The two were done at the same time (in different subgroups of ANSI X3T9) but with no significant connection between them. FDDI was 100 Mb/s, Fibre Channel was initially 800 Mb/s (not 1 Gb/s -- FC has always committed false advertising by reporting the baud rate of the encoded signal rather than the payload rate -- if Ethernet had done things in FC terms then 10 Mb/s Ethernet would have been called 20 Mb/s Ethernet). And even the PHY is completely different: 4b/5b coding for FDDI, 8b/10b for F
C.
I see, my memory didn't serve me right then. I thought FC was developed later than FDDI and that FC had adopted the similarities from FDDI.
Sorry about the confusion. I should dust off my bookshelf and reread the books about FDDI and FC to refresh my memory.
As I mentioned before, FDDI was based on 802.4 (token bus) MAC layer algorithms ("timed token protocol"), with vast quantities of complexity added on top. (Partly that was done by some of the participants to delay the standard by a couple of years.) Fast Ethernet adopted the 4b/5b encoding from FDDI, but apart from that it was a technological dead end.
paul
.
Kari
On 2013-10-11 17:22, Mark Darvill wrote:
It would be worth looking at v2.5 and 3 as I seem to remember that the graphics did improve but it was wire line but was neat for a late 80's internal project.....
Well, I worked at DEC back in 86, and it worked pretty well back then. I don't think even the 3100 had been introduced yet. We had VAXstation I and VAXstation II machines around, and that was it.
Johnny
We did run it on Vaxstations of various types including 4000/60's but also used to X out of big vaxes such as the 9000 we had in my last stint at DEC.
Mark
On 11 Oct 2013, at 17:15, Mark Wickens <mark at wickensonline.co.uk> wrote:
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
That's odd, my VS 4000/60 and /90A also show non Dec branded disks on the >>> sho dev command.
Must check that owing to failing organic memory...
Van: Mark Wickens
Verzonden: vrijdag 11 oktober 2013 09:17
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] SSD for Vax
On 11/10/2013 01:52, Daniel Soderstrom wrote:
> http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
>
> This adapter is available on ebay for $149 and he says they work well in Vaxstations. He also has some which take CF flash cards.
>
> Regards,
>
> Daniel,
>
>
Thanks for the link Daniel. This is great news. I know that there have
been various incarnations of adapters that have come and gone and been
niche enough that there hasn't been reliable evidence of their
functionality computers with older scsi implementations. Typically they
are built to support equipment in the music industry.
Anything that provides us a way forward is definitely a good thing! I
don't like noisy hard drives any more than the next person.
I will have to explore my theory of the 18GB limit on the VAXstation
4000/60 and /90 and I thought that was a hard rule, but I'm happy to be
proved wrong. It may be that I was using an earlier version of VMS where
it definitely is the case that only certain models of drive are
supported. I had to root around to find a supported drive for OpenVMS
6.1 - even generic Seagate 50 pin SCSI 2.1GB drives weren't recognised
because they aren't RZ* tagged in the firmware.
Regards, Mark.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
It would be worth looking at v2.5 and 3 as I seem to remember that the graphics did improve but it was wire line but was neat for a late 80's internal project.....
We did run it on Vaxstations of various types including 4000/60's but also used to X out of big vaxes such as the 9000 we had in my last stint at DEC.
Mark
On 11 Oct 2013, at 17:15, Mark Wickens <mark at wickensonline.co.uk> wrote:
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
On Oct 11, 2013, at 10:50 AM, Cory Smelosky <b4 at gewt.net> wrote:
On Fri, 11 Oct 2013, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
SAS or SATA or SATA to SAS? SATA can run on SAS easily so I assume you do mean SAS to SATA.
Depends on what direction you look. Yes, SAS controllers can talk to SATA disks, with some level of success. (This is actually rather hard and strange bugs show up in this area.) I meant the protocol translation, for example for a SATA controller to talk to a SAS disk.
paul
Back when I had RSX 11M+ on a 11/44 with massbus, I looked and looked for a ML-11 to try out. Never did find one. The application was electron-beam lithography, we were trying to write holograms, and under certain conditions the hardware was always waiting around for the pattern data from the disk. We also ended up doing on-the-fly data decompression to reduce the size of the pattern on the disk, which made the throughput situation *worse*. (That's when I discovered "fast-mapping" under M+, which is by the way very cool.) The ML-11, had I been able to find one, might have helped significantly.
--Mike
On Oct 11, 2013, at 10:27 AM, Cory Smelosky <b4 at gewt.net> wrote:
On Fri, 11 Oct 2013, Johnny Billquist wrote:
On 2013-10-10 18:39, Hans Vlems wrote:
DEC had solid state disks, all das iirc
DEC had solid state disks already in the 70s. It was called the ML-11. Massbus interface even...
Now THAT is neat.
Johnny
On 2013-10-10 09:46, Mark Wickens wrote:
On 10/10/2013 08:17, Daniel Soderstrom wrote:
Has anyone tries this? Running my Vaxstation non-stop reminds me how
much noise these old drives make.
Has anyone tried SSD drives? Must be good for the PSU it terms of heat
and current draw.
Daniel
There has been very little success with IDE to SCSI converters on this
age of machine.
Hmm. bad IDE to SCSI converters?
Remember also that even 4000/90 vintage VAXstations generally have an
upper limit of 18GB.
Uh? That got to be a limit in VMS in that case. I can't see how the
hardware would have that limit.
I don't recall anyone even getting an IDE drive to work, let alone an
SSD.
IDE and SSD are two completely unrelated things as such. However, if the
SSD have an IDE interface, then you obviously need the IDE to SCSI
converter.
Would love to be proved wrong however! I'm surprised someone hasn't
written a software based SCSI drive emulator the same way that you get
floppy emulators.
Probably mostly because of speed issues. You have some very tight timing
requirements, and a SCSI interface runs way faster than a floppy.
Consider running the machine diskless, booted off the network with
off-node disks.
That definitely also works.
Johnny
--
Cory Smelosky
Michael Young
young at ecn.purdue.edu
On Fri, 11 Oct 2013, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
SAS or SATA or SATA to SAS? SATA can run on SAS easily so I assume you do mean SAS to SATA.
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
There are plenty of CF or SD cards under 18gb. Also, there must be some way of only using part of a drive, as these cards are used extensively in old Macs which have a 170mb boot drive limit.
I'm fully aware of that, in fact I plan to try using a 4GB CF card on my 4000/60 at some stage to see what it does. You linked to a *SATA* to SCSI adapter intended for use on hard drives?
I'm aware that SATA to CF/SD adapters are available, I used one for a while with a CF card. That may be an option but like others have said the reliability can be variable. Also some companies that offer embedded micro-PC stuff also sell 8GB and 16GB SATA SSDs that might be an option too, maybe? I am fairly sure I have a 16GB one spare somewhere.
CF and SD are both flash storage cards, but they have completely different interfaces.
CF is SATA with a different connector. A CF to SATA adapter is nothing more than a pair of connectors and some wires.
SD uses a serial packet protocol, a generalization of the one used by MMC devices. It's not SCSI, but it feels a bit like it because of that packet and command/response style of doing things. Also, SD has an extremely complex and strange initialization sequence.
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
paul
