On 10/11/2013 02:13 AM, Mark Benson 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.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
WHY does this keep coming up? There is no such limitation!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
No, that would not be legal (and in fact the DEC FDDI chips contain specific machinery to detect and remove duplicate tokens should any show up). Sridhar was talking about a switch (bridge), so each port is a separate LAN and as such has its own circulating token.
paul
On Oct 11, 2013, at 2:04 PM, Hans Vlems <hvlems at zonnet.nl<mailto:hvlems at zonnet.nl>> wrote:
Wouldn't that mean more than one token on a ring?
Van: Sridhar Ayengar
Verzonden: vrijdag 11 oktober 2013 19:55
Aan: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Beantwoorden: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Onderwerp: Re: [HECnet] FDDI advice
Paul_Koning at Dell.com<mailto:Paul_Koning at Dell.com> wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for
each port? Isn't that how switched-FDDI works?
Peace... Sridhar
Wouldn't that mean more than one token on a ring?
Van: Sridhar Ayengar
Verzonden: vrijdag 11 oktober 2013 19:55
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] FDDI advice
Paul_Koning at Dell.com wrote:
> Half duplex Ethernet slows down when there are collisions, but there
> is no wait to transmit whenever the link is idle. With FDDI, there
> is (you wait for the token). So at high load, half duplex Ethernet
> might be a little slower than FDDI, but at modest load, it will
> definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for
each port? Isn't that how switched-FDDI works?
Peace... Sridhar
On Oct 11, 2013, at 1:55 PM, Sridhar Ayengar <ploopster at gmail.com> wrote:
Paul_Koning at Dell.com wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for each port? Isn't that how switched-FDDI works?
On token LANs there's a token per LAN. Yes, if you bridge token LANs, each LAN has its own token. That's true for all bridges, it's a consequence of what a bridge is.
But still, on any one LAN, the stations have to wait for the token. That is, unless you have exactly two MACs, and they are DEC stations that support the DEC full duplex mode. If so, you have no token, and the link operates essentially the same as Ethernet in full duplex mode (except for header format and min/max packet sizes).
paul
Paul_Koning at Dell.com wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for each port? Isn't that how switched-FDDI works?
Peace... Sridhar
On Oct 11, 2013, at 1:25 PM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
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.
Yes, the smaller packet size of Ethernet means the CPU does per-packet processing 3 times as often, which has a performance impact. (Pretty small, if the CPU is fast.) And three headers instead of one makes a difference, but only a bit over 1%.
Half duplex Ethernet slows down when there are collisions, but there is no wait to transmit whenever the link is idle. With FDDI, there is (you wait for the token). So at high load, half duplex Ethernet might be a little slower than FDDI, but at modest load, it will definitely be faster (lower latency).
paul
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
