From: Johnny Billquist <bqt at softjar.se>
But is there any sane reason
why Linux would SYN-ACK twice, and the second one more than a second
after the first.
Completely stupid theory: last time I did any testing with Linux, it seemed
that it would *always* lose the very first packet sent to a given local
IP address, because it would send an ARP request instead and then forget
why it asked (i.e. drop the outgoing frame since it depended, IMHO wrongly,
on the higher-level protocol to time out and resend). Maybe they fixed
that bug twice? I.e. did a workaround to send the SYN+ACK twice, and then
later did the *real* bug fix to maintain a queue of packets waiting for an
ARP reply, so now you get two? Seems silly but this would be the result.
John Wilson
D Bit
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I think looks funny in Linux. But right now my head is also spinning, so maybe there is something I've just forgotten, or don't know, which explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but it's not really hurting anything, but I like my TCP/IP to really do things as right and optimal as possible.
So, I actually have two scenarios that I'm looking at. The first one is the initial setup. You know, the old three way handshake. Here is a tcpdump between a Linux box and my RSX. Psilo being Linux, and Madame being RSX, and connection initiated from RSX to Linux:
01:02:06.567423 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [S], seq 2810750936, win 5840, options [mss 1460], length 0
01:02:06.567435 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:06.569071 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0
01:02:07.966015 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:07.967524 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0
Notice how I get two SYN-ACK packets in quick succession from Linux. I ack both, and connection is established. But is there any sane reason why Linux would SYN-ACK twice, and the second one more than a second after the first.
I should point out that the tcpdump is being run on Psilo (the Linux box in question), so the packet definitely found its way to Psilo, so I don't think lost packet is the answer. Also, it is very repeatable.
Second issue. During a session I see the following. Data transferred from RSX to Linux:
01:10:23.065711 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 17521:18981, ack 27, win 5840, length 1460
01:10:23.065715 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 18981, win 52560, length 0
01:10:23.106052 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 18981:20441, ack 27, win 5840, length 1460
01:10:23.106055 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 20441, win 55480, length 0
01:10:23.146201 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 20441:21901, ack 27, win 5840, length 1460
01:10:23.146205 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 21901, win 58400, length 0
01:10:23.181855 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 21901:23361, ack 27, win 5840, length 1460
01:10:23.181859 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 23361, win 61320, length 0
01:10:23.215162 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 23361:24821, ack 27, win 5840, length 1460
01:10:23.215166 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 24821, win 62780, length 0
Notice how Psilo ACKs every fricking message immediately. No delayed ACKs at all. And the announced window is plenty larger. I could have sent another 30 messages before that window was exhausted.
I could possibly believe that in todays world a window of 50K could be considered "almost exhausted" and so immediate window updates when possible, but it do seem a bit silly, and spams the network with lots of unneccesary ACK packets here.
Any thoughts, opinions or knowledge always welcome.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I can not speak for VMS, but I can speak for NT and Tru64.
The official (standard) DEC SCSI (and Sun Solaris) controller was based on the QLogic device in ISP*40/50/60/80 boards. I do not remember why we picked them, there must have been features that Adaptec did not support that Qlogic did. My memory is they were "triple" board that supported Network, SCSI and something else -- ???floppy maybe??.
At the that time ( mid late 1990s ) NT did not work/support/was qualified with the Qlogic (NT only supported the NCR, LSI/Buslogic and Adaptec chips). Thus DEC had to ship the 2940 based in the Alpha/NT systems. This forced the boot ROMs from then on to have the code to deal with them. IIRC from Turbo lasers on that code to support Adaptec SCSI chips was "in there."
At the time, I do not believe the Tru64 SPD officially support them (I do not remember the details - there was some issues with fail-over on TruClusters), but the OS could recognize them, and even boot from them and a lot of smaller machines, particularly repurposed Alpha/NT systems ran that way (the Tru64 based Alpha on my own desk in MRO & ZK0 had one in it -- as did most if not all of them in our Lab).
When we trying to build the $1K Alpha (i.e. we replaced the Compaq based AMD K8 with and EV6 - long story), we used the Adaptec board so Tru64 could "just work" and I seem to remember there was an issue with Qlogic boards which was never solved. (Too many beers ago, but I know VMS would not boot but I've forgotten why. I think I remember that it was because VMS did not have the native support for the Adaptec chips).
Funny - years later, I do not think I have Qlogic boards in my "museum" - but I know I have 4 or 5 Adaptecs in box somewhere.
On Thu, Feb 14, 2013 at 11:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/14/2013 11:15 PM, Cory Smelosky wrote:
> Mine are pretty much like those, except the internal connector is
> parallel, they work with VMS, and they're not parallel SCSI inside.
If they're not parallel SCSI inside, then what are they?
The ISP1080 (I think you mentioned your board is ISP1080-based) is a
pretty common PCI to SCSI host adapter chip. Nearly all of the required
circuitry is on that chip.
What Gregg was looking for was, I think, something from the Adaptec
AHA2940 family. Different chip, same basic idea, just as common, but
incompatible at the register level.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 15.2.2013 15:45, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
Does Galaxy with hard partitions let you run different OSes or are you
limi= ted to VMS?
Galaxy is an OpenVMS technology. Hard partition is the technology within
the console firmware. It *may* be possible to run different OSs using the
hard partitioning (I never tried it or even thought to) but you wouldn't
be able to do things Galaxy provides such as CPU migration. Regardless,
you cannot do it on an ES40. You'd need one of the GS class systems.
It is possible to run different OS's on different hard partitions. I've done that personally on Alpha GS-series machines (using VMS and Tru64) and Integrity rx7xxx, rx8xxx and Superdomes (using VMS and HP-UX).
But then there aren't any shared resources like Brian said. Hard partitioning means really that a machine can be split into completely independent partitions so that there is no way to interact with the other partitions through the HW. Only external connections are possible.
In any case the manual is good reading to get a picture about what partitioning and Galaxy means in real life. The marketing material might give you a too dizzy picture about it.
Kari
Nope. The wordin is subtle but the ES40 is all one hardware partition so only soft partitions are available meaning you can only create OpenVMS Galaxy members.
The GS series and the ES47 are different hardware than the ES40/45 and have separate I/O drawers and PCI busses, etc.
John H. Reinhardt
On 2/15/2013 9:37 AM, Cory Smelosky wrote:
----- Original Message -----
| From: "Brian Schenkenberger, VAXman-"<system at TMESIS.COM>
| To: hecnet at Update.UU.SE
| Sent: Friday, 15 February, 2013 9:29:28 AM
| Subject: Re: [HECnet] Galaxy questions
|
| Cory Smelosky<b4 at gewt.net> writes:
|
|>I am citing
|>http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf
|>chapter 8. Limited to 2 instances.
|
| Soft partition.
Really? Even though it requires dedicated network and disk hardware per-partition? I thought only hard partitions required that.
|
| --
| VAXman- A Bored Certified VMS Kernel Mode Hacker
| VAXman(at)TMESIS(dot)ORG
|
| Well I speak to machines with the voice of humanity.
|
----- Original Message -----
| From: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM>
| To: hecnet at Update.UU.SE
| Sent: Friday, 15 February, 2013 9:29:28 AM
| Subject: Re: [HECnet] Galaxy questions
|
| Cory Smelosky <b4 at gewt.net> writes:
|
| >I am citing
| >http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf
| >chapter 8. Limited to 2 instances.
|
| Soft partition.
Really? Even though it requires dedicated network and disk hardware per-partition? I thought only hard partitions required that.
|
| --
| VAXman- A Bored Certified VMS Kernel Mode Hacker
| VAXman(at)TMESIS(dot)ORG
|
| Well I speak to machines with the voice of humanity.
|
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Experiments
http://dev.gimme-sympathy.org Home experiments
Cory Smelosky <b4 at gewt.net> writes:
I am citing
http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf
chapter 8. Limited to 2 instances.
Soft partition.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
----- Original Message -----
| From: "Cory Smelosky" <b4 at gewt.net>
| To: hecnet at Update.UU.SE
| Cc: hecnet at Update.UU.SE
| Sent: Friday, 15 February, 2013 9:07:05 AM
| Subject: Re: [HECnet] Galaxy questions
|
|
|
| --
| Cory Smelosky
| Sent from a mobile device
|
| On 15 Feb 2013, at 08:45, "Brian Schenkenberger, VAXman-"
| <system at TMESIS.COM> wrote:
|
| > Cory Smelosky <b4 at gewt.net> writes:
| >
| >> Does Galaxy with hard partitions let you run different OSes or are
| >> you
| >> limi= ted to VMS?
| >
| > Galaxy is an OpenVMS technology. Hard partition is the technology
| > within
| > the console firmware. It *may* be possible to run different OSs
| > using the
| > hard partitioning (I never tried it or even thought to) but you
| > wouldn't
| > be able to do things Galaxy provides such as CPU migration.
| > Regardless,
| > you cannot do it on an ES40. You'd need one of the GS class
| > systems.
|
| I thought the es40 could do hard partitioning?
I am citing http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf chapter 8. Limited to 2 instances.
|
| >
| > --
| > VAXman- A Bored Certified VMS Kernel Mode Hacker
| > VAXman(at)TMESIS(dot)ORG
| >
| > Well I speak to machines with the voice of humanity.
|
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Experiments
http://dev.gimme-sympathy.org Home experiments
--
Cory Smelosky
Sent from a mobile device
On 15 Feb 2013, at 08:45, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Cory Smelosky <b4 at gewt.net> writes:
Does Galaxy with hard partitions let you run different OSes or are you
limi= ted to VMS?
Galaxy is an OpenVMS technology. Hard partition is the technology within
the console firmware. It *may* be possible to run different OSs using the
hard partitioning (I never tried it or even thought to) but you wouldn't
be able to do things Galaxy provides such as CPU migration. Regardless,
you cannot do it on an ES40. You'd need one of the GS class systems.
I thought the es40 could do hard partitioning?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Ok, thanks Kari. ISTR that early galaxy tests were done on an AS2100.
-----Original Message-----
From: Kari Uusim ki <uusimaki at exdecfinland.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 15 Feb 2013 15:39:21
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Galaxy questions
Neither one.
Of the older servers the AS4100 and ES40 can be configured into a Galaxy.
The newer ones like ES45, ES47 (m4), and all of the GS series machines
can be configured into Galaxy.
Kari
On 15.2.2013 15:25, hvlems at zonnet.nl wrote:
I tried to set up a galaxy on an AS1200 which failed. Lazy that I am, not rtfm-ing, would a DS20E do ?
------Origineel bericht------
Van: Brian Schenkenberger, VAXman-
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Galaxy questions
Verzonden: 15 februari 2013 14:19
=?ISO-8859-1?Q?Kari_Uusim=E4ki?= <uusimaki at exdecfinland.org> writes:
Yes, an ES40 can be configured as a Galaxy node.
In a Galaxy there are two (or more in bigger machines) "logical" nodes
(Instances) which run separately, but can also share resources like CPUs
so that the CPUs can be moved from each instance to the other.
Shortest definition: cluster in a box with shared memory serving as the
cluster interconnect. DLM traffic just wizzes by in a Galaxy.
You need a license called GALAXY, which is unfortunately not among the
Hobbyist licenses.
I thought HP were proving all sort of OpenVMS license PAK options for the
hobbyist. I guess I'll have to register as one and see what they are now
offering. My systems *do* all have OPENVMS-GALAXY PAKs; too bad hobbyist
don't get them too. I wonder if a plea to the HP Hobbyist program would
change this?
Why don't you read the manual to get a picture about Galaxy and its
functionality. It might be easier to discuss the matter then.
http://h71000.www7.hp.com/doc/732FINAL/aa-rezqe-te/aa-rezqe-te.PDF
Yes, R-TFM. Save for some SRM variables, init and lpinit, and configuring
OpenVMS for Galaxy (usually, a question early in the installation/upgrade
process of OpenVMS but a quick trek through SYSGEN/SYSMAN to set aside the
memory for its shared -- galactic -- memory and setting the parameter to
enable Galaxy) I don't see anything preclude a Galaxy other than licensing
requirements.
