Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
HP TCP/IP NFS and S/FTP
195 views
Skip to first unread message
MG
Dec 9, 2012, 12:49:47 PM12/9/12
to
Has anyone gotten these to function at acceptable speeds?
(Yes, I have jumbo frames and such enabled.)
I gave up, well, as far as HP TCP/IP Services NFS, FTP,
SFTP, etc. go. MultiNet seems fine, but I don't think
it's worth the hassle to mess around with additional
PAKs, neither did I like the configuration interface
much.
Anyway, I simply installed CIFS and I'm getting much
better transfer speeds. Still not excellent, but a
lot better overall. To give you an indication. I was
occasionally dealing with ~350 kbytes/sec. occasionally,
with regular FTP (I gave up on SFTP a while ago, with
all the annoyances involved with the file system).
NFS was also a major pain, the configuration is awful
and I've discovered strange bugs/'features' (who's to
say?), like that one can't export a remote share with
an asterisk (e.g. to cover an entire subnet-range),
else the NFS client apparently won't see it.
What do most of you use and does(n't) it bother you,
the transfer speeds? Or, how did you optimize it?
Most solutions I come by are either incomplete or
complete workarounds.
If HP wants to kill VMS from a functional perspective,
they definitely need to keep it up and don't change a
thing.
- MG
(Yes, I have jumbo frames and such enabled.)
I gave up, well, as far as HP TCP/IP Services NFS, FTP,
SFTP, etc. go. MultiNet seems fine, but I don't think
it's worth the hassle to mess around with additional
PAKs, neither did I like the configuration interface
much.
Anyway, I simply installed CIFS and I'm getting much
better transfer speeds. Still not excellent, but a
lot better overall. To give you an indication. I was
occasionally dealing with ~350 kbytes/sec. occasionally,
with regular FTP (I gave up on SFTP a while ago, with
all the annoyances involved with the file system).
NFS was also a major pain, the configuration is awful
and I've discovered strange bugs/'features' (who's to
say?), like that one can't export a remote share with
an asterisk (e.g. to cover an entire subnet-range),
else the NFS client apparently won't see it.
What do most of you use and does(n't) it bother you,
the transfer speeds? Or, how did you optimize it?
Most solutions I come by are either incomplete or
complete workarounds.
If HP wants to kill VMS from a functional perspective,
they definitely need to keep it up and don't change a
thing.
- MG
Steven Schweda
Dec 9, 2012, 2:39:13 PM12/9/12
to Steven M. Schweda
> Has anyone gotten these to function at acceptable speeds?
Sure (FTP, NFS), but my standards are low. Define
"acceptable".
> [...] CIFS [...] much better transfer speeds.
Define "much better".
> [...] dealing with ~350 kbytes/sec [...]
When you did _what_, exactly? With what as a client? Are
you including NFS automount start-up time?
> [...] VMS [...]
Not a very detailed description of anything.
tcpip show version
No matter how dissatisfied you may be, a problem
description which is incomplete/sloppy to the point of
uselessness may not be the best way to gain useful
information.
> [...] don't change a thing.
That seems to be a consequence of the general plan (which
seems to be to spend minimal money on development).
Jan-Erik Soderholm
Dec 9, 2012, 3:08:18 PM12/9/12
to
MG wrote 2012-12-09 18:49:
> To give you an indication. I was
> occasionally dealing with ~350 kbytes/sec. occasionally,
> with regular FTP...
> To give you an indication. I was
> occasionally dealing with ~350 kbytes/sec. occasionally,
This is between two DS20 (666 MHz) on 100 Mb/s LANs.
One VMS 8.2 and the other VMS 8.4 :
FTP> get cccc.RBF
200 PORT command successful.
150 Opening data connection for disk:<dev.dev>cccc.RBF;
(n.n.n.n) (5512647168 bytes)
226 Transfer complete.
local: disk:<dev>cccc.RBF;2 remote: cccc.RBF
5512647168 bytes received in 00:09:48.12 seconds (8.94 Mbytes/s)
FTP>
Close to 9 MB/s (or aprox 70 Mb/s) over 100 Mb/s LAN is quite
acceptable for me.
Jan-Erik.
Jan-Erik Soderholm
Dec 9, 2012, 5:38:20 PM12/9/12
to
had missmatched full/half duplex setings between the servers
and the corresponding switches...
Jan-Erik.
David Froble
Dec 9, 2012, 6:06:52 PM12/9/12
to
who still demand VMS, but not doing a thing for them.
MG
Dec 9, 2012, 7:06:23 PM12/9/12
to
On 9-dec-2012 20:39, Steven Schweda wrote:
> Sure (FTP, NFS), but my standards are low. Define
> "acceptable".
Which operating systems/platforms do you use besides VMS?
> Sure (FTP, NFS), but my standards are low. Define
> "acceptable".
It can then indeed be hard to define, without knowing what
to compare it with and without knowing what you're used to
and/or familiar with.
I can tell you, that my VMS transfer speeds with HP TCP/IP
Services NFS, FTP, SFTP, etc. are on average two to five
times as slow as on other, even far older, platforms and
with less impressive (networking) hardware. Well, in my
estimation. I hope my estimation is good enough for you,
I'm not exactly running benchmarks and agitated as it is
already by these frustratingly slow speeds.
I occasionally want to get something done. Well, you know,
without it taking forever...
> Define "much better".
>
>> [...] dealing with ~350 kbytes/sec [...]
>
> When you did _what_, exactly? With what as a client?
> Are you including NFS automount start-up time?
it's extremely irregular... or rather random, if you will.
I'm generalizing obviously. As for NFS, no, I avoid NFS
and I in particular try to avoid HP TCP/IP Services NFS.
The best I ever recall to have achieved was something like
15~20 Mbytes/sec. from VMS to a non-VMS system via regular
FTP, SFTP never even came close (plus the incompleteness,
lack of features that regular FTP offers). I also didn't
change my networking/switch setup either and other systems
in the network and on the same switch don't give any of
these issues. In fact, even with host to host connections,
even 10GbE, I get very poor results.
I once got something like ~90 Mbytes/sec. with a GbE link
(regular, copper, 1000BASE-TX), but that was probably a
bad estimation (as a result of a smaller file size and
skewed estimate or simply a miscalculation).
The worst offender, as far as poor performance goes, is
incoming connections, i.e. to a VMS host. I've changed
all sorts of settings, from simple and straightforward
things like enabling jumbo frames (which I do in general,
as most of my systems have jumbo frames enabled on the
capable NICs).
>> [...] VMS [...]
>
> Not a very detailed description of anything.
>
> tcpip show version
You know what's available, what HP distributes, so you
can more or less guess what I'm running. (I'm a Hobbyist
Program partaker.)
Also, I can tell you that I've gotten roughly the same
results with and without certain extras. The results
have been poor and I've seen other/earlier comp.os.vms,
ITRC, EBC, etc. threads with the same complaints and
often without solutions or remedies. (At best poor
workarounds.)
> No matter how dissatisfied you may be, a problem
> description which is incomplete/sloppy to the point of
> uselessness may not be the best way to gain useful
> information.
then. For one thing, I'm not trying to specifically 'gain'
anything. I'm not trying to solve a specific issue, I'm
not exactly 'troubleshooting' with this thread, now am I?
Consider it general criticism, or a rant, if you will.
Pointless, I guess, but I'm mostly interested what others
are doing (assuming others care for network and notably
file transfer performance).
>> [...] don't change a thing.
>
> That seems to be a consequence of the general plan
> (which seems to be to spend minimal money on development).
things, I think it's not hard to see where things are heading
to... Corporate liquidation?
- MG
MG
Dec 9, 2012, 7:11:13 PM12/9/12
to
On 9-dec-2012 21:08, Jan-Erik Soderholm wrote:
> This is between two DS20 (666 MHz) on 100 Mb/s LANs.
> One VMS 8.2 and the other VMS 8.4 :
>
> [...]
> This is between two DS20 (666 MHz) on 100 Mb/s LANs.
> One VMS 8.2 and the other VMS 8.4 :
>
Purely out of curiosity, but why would you even use FTP and why
not VMScluster & MSCP or even DECnet? Also, from and to which
kind and type of storage do you read from and write to?
> Close to 9 MB/s (or aprox 70 Mb/s) over 100 Mb/s LAN is quite
> acceptable for me.
That's not bad, that's close to the link speed. Do you use
> acceptable for me.
HP TCP/IP Services?
- MG
MG
Dec 9, 2012, 7:13:16 PM12/9/12
to
On 9-dec-2012 23:38, Jan-Erik Soderholm wrote:
> Forgot to add, this was extremly bad before we discovered that
> we had missmatched full/half duplex setings between the servers
> and the corresponding switches...
Yes, I remember I also ran into some trouble with regard to
> Forgot to add, this was extremly bad before we discovered that
> we had missmatched full/half duplex setings between the servers
> and the corresponding switches...
that. I managed to fix that, or align it, but I'm still not
getting very impressive results.
The other day I was reading that these problems, in terms of
general network/data transfer slowness, was already known and
discussed at Compaq and mentioned in documents comparing Tru64
UNIX and VMS...
- MG
Steven Schweda
Dec 9, 2012, 9:38:30 PM12/9/12
to Steven M. Schweda
> Which operating systems/platforms do you use besides VMS?
I'm sorry to be so stupid, but why should _I_ provide an
inventory of _my_ stuff when you seem unwilling to disclose
any useful information about what you're doing, with what,
how?
> tcpip show version
Which part of that was unclear?
> V8.4 plus extras, but you don't need to know the details.
possibly matter.
> You know what's available, what HP distributes, so you
> can more or less guess what I'm running.
more valuable to me than it is to you.
Jan-Erik Soderholm
Dec 10, 2012, 3:54:41 AM12/10/12
to
MG wrote 2012-12-10 01:11:
> On 9-dec-2012 21:08, Jan-Erik Soderholm wrote:
>> This is between two DS20 (666 MHz) on 100 Mb/s LANs.
>> One VMS 8.2 and the other VMS 8.4 :
>>
>> [...]
>
> Purely out of curiosity, but why would you even use FTP...
> On 9-dec-2012 21:08, Jan-Erik Soderholm wrote:
>> This is between two DS20 (666 MHz) on 100 Mb/s LANs.
>> One VMS 8.2 and the other VMS 8.4 :
>>
>> [...]
>
in *this* case, it was becuse that was what you refered to.
But in generel, becuse it's simple and available.
> and why not VMScluster & MSCP or even DECnet?
quite sure that DECnet would be slower anyway (if *speed*
is the primarily goal here).
> Also, from and to which
> kind and type of storage do you read from and write to?
>
and the DS20 "server" has HSZ/HSG controllers. I do not
thing that is mayor issue, the servers was on aprox
200 disk I/O per sec during the transfer which simpler
disk configs should be able to supply also.
The HSZ/HZG tops at aprox 700 I/O per sec and the
DS2000 at something like 2.000 I/O per sec.
>
>> 5512647168 bytes received in 00:09:48.12 seconds (8.94 Mbytes/s)
>>
>> Close to 9 MB/s (or aprox 70 Mb/s) over 100 Mb/s LAN is quite
>> acceptable for me.
>
> That's not bad, that's close to the link speed. Do you use
> HP TCP/IP Services?
And yes, this is not only acceptabel, it is way over our
real needs, which is the important point here of course.
I never realy understood what your actual need is, but if you
get realy poor results, it might be some misconfig somewhere.
Jan-Erik.
Jan-Erik Soderholm
Dec 10, 2012, 4:04:52 AM12/10/12
to
MG wrote 2012-12-10 01:06:
>>> [...] VMS [...]
>>
>> Not a very detailed description of anything.
>>
>> tcpip show version
>
> V8.4 plus extras, but you don't need to know the details.
A terrible bad attitude there. Of course we need to know
>>> [...] VMS [...]
>>
>> Not a very detailed description of anything.
>>
>> tcpip show version
>
> V8.4 plus extras, but you don't need to know the details.
the details if there should be any point with the thread.
> and I've seen other/earlier comp.os.vms,
> ITRC, EBC, etc. threads with the same complaints and
> often without solutions or remedies. (At best poor
> workarounds.)
point whith *this* thread? Besides showing of your bad
attitude?
>
> Pointless, I guess,...
More and more so, yes.
VMS has a number of strengths, but raw network speed might
not (always) be one of them. So what ??
MG
Dec 10, 2012, 7:33:15 AM12/10/12
to
On 10-dec-2012 3:38, Steven Schweda wrote:
> I'm sorry to be so stupid, but why should _I_ provide an
> inventory of _my_ stuff when you seem unwilling to disclose
> any useful information about what you're doing, with what,
> how?
You asked me to "define acceptable" and you wrote that your
> I'm sorry to be so stupid, but why should _I_ provide an
> inventory of _my_ stuff when you seem unwilling to disclose
> any useful information about what you're doing, with what,
> how?
"standards are low". We (or I was) talking about a comparison,
VMS in its current shape in relation to other platforms.
> Right. Alpha, IA64, ECO-X, ... None of that could
> possibly matter.
the (renewed and insourced) Hobbyist Program.
More importantly, if it had been a specific architecture that
gave me issues, I would've found out about it by now and I
wouldn't have been speaking of VMS in general.
> I can guess all kinds of things, but my time is apparently
> more valuable to me than it is to you.
Program, is what I meant. (Assuming you're a partaker, like me,
as well.)
More importantly, I wasn't demanding your help. I wasn't asking
for help at all, I'm not 'troubleshooting' or trying to 'fix' a
specific thing (as I already stated in my previous reply).
I'm just trying to 'poll', openly wondering if people are as
'satisfied' as I am about the points I brought up.
- MG
MG
Dec 10, 2012, 7:37:16 AM12/10/12
to
On 10-dec-2012 10:04, Jan-Erik Soderholm wrote:
> A terrible bad attitude there. Of course we need to know
> the details if there should be any point with the thread.
Not just bad, terrible bad? Why not extremely very terrible
> A terrible bad attitude there. Of course we need to know
> the details if there should be any point with the thread.
bad? Now it feels like I didn't get the high score.
>> Pointless, I guess,...
>
> More and more so, yes.
something either.
> VMS has a number of strengths, but raw network speed might
> not (always) be one of them. So what ??
just like to get something done.
- MG
MG
Dec 10, 2012, 7:39:03 AM12/10/12
to
On 10-dec-2012 9:54, Jan-Erik Soderholm wrote:
> in *this* case, it was becuse that was what you refered to.
> But in generel, becuse it's simple and available.
Because I'm comparing VMS to non-VMS environments.
> in *this* case, it was becuse that was what you refered to.
> But in generel, becuse it's simple and available.
> No cluster here. I'm not sure DECnet is started. And I'm
> quite sure that DECnet would be slower anyway (if *speed*
> is the primarily goal here).
> I never realy understood what your actual need is, but if you
> get realy poor results, it might be some misconfig somewhere.
realLy need to know everything of me either. You know, some
things are private.
- MG
Jan-Erik Soderholm
Dec 10, 2012, 8:03:45 AM12/10/12
to
MG wrote 2012-12-10 13:37:
>> VMS has a number of strengths, but raw network speed might
>> not (always) be one of them. So what ??
>
> That's a way of putting it, I guess... Well, sometimes I
> just like to get something done.
So do I. :-)
>> VMS has a number of strengths, but raw network speed might
>> not (always) be one of them. So what ??
>
> That's a way of putting it, I guess... Well, sometimes I
> just like to get something done.
So I just couldn't care less if VMS is slower then
"something else" when FTP'ing. I'm working on VMS for
paying customers and the speed of FTP is not on the
current agenda. It's definitely "good enough"...
Jan-Erik.
Jan-Erik Soderholm
Dec 10, 2012, 8:05:52 AM12/10/12
to
MG wrote 2012-12-10 13:33:
> I'm just trying to 'poll', openly wondering if people are as
> 'satisfied' as I am about the points I brought up.
>
> - MG
Yes, I'm satisfied (with the speed of FTP).
> I'm just trying to 'poll', openly wondering if people are as
> 'satisfied' as I am about the points I brought up.
>
> - MG
Jan-Erik Soderholm
Dec 10, 2012, 8:08:47 AM12/10/12
to
MG wrote 2012-12-10 13:39:
> On 10-dec-2012 9:54, Jan-Erik Soderholm wrote:
>> in *this* case, it was becuse that was what you refered to.
>> But in generel, becuse it's simple and available.
>
> Because I'm comparing VMS to non-VMS environments.
>
You have not specified your actual environments.
> On 10-dec-2012 9:54, Jan-Erik Soderholm wrote:
>> in *this* case, it was becuse that was what you refered to.
>> But in generel, becuse it's simple and available.
>
> Because I'm comparing VMS to non-VMS environments.
>
>
>> No cluster here. I'm not sure DECnet is started. And I'm
>> quite sure that DECnet would be slower anyway (if *speed*
>> is the primarily goal here).
>
> Remarkable...
>
>
>> I never realy understood what your actual need is, but if you
>> get realy poor results, it might be some misconfig somewhere.
>
> You don't realLy need to 'understand' everything. You don't
> realLy need to know everything of me either. You know, some
> things are private.
Jan-Erik.
MG
Dec 10, 2012, 8:13:14 AM12/10/12
to
On 10-dec-2012 14:08, Jan-Erik Soderholm wrote:
>> Because I'm comparing VMS to non-VMS environments.
>>
>
> You have not specified your actual environments.
I wasn't aware that it was mandatory. Maybe you can try to use
>> Because I'm comparing VMS to non-VMS environments.
>>
>
> You have not specified your actual environments.
your imagination? There aren't too many viable left nowadays,
more like a handful (in terms of hardware platforms).
>>> No cluster here. I'm not sure DECnet is started. And I'm
>>> quite sure that DECnet would be slower anyway (if *speed*
>>> is the primarily goal here).
>>
>> Remarkable...
>
> What is ?
experience goes with it.
- MG
Jan-Erik Soderholm
Dec 10, 2012, 9:09:07 AM12/10/12
to
nice features (for DECnet the main one is the integration
with VMS, of course), but raw speed has never been one
of them.
But again, it was/is usualy "good enough". That some other
plattform might clock a higher raw speed doesn't say that the
speed of VMS, DECnet or TCPIP/Services isn't "good enough".
What is you actual application where the current speed of
whatever-you-are-doing isn't good enough ?
Jan-Erik.
Stephen Hoffman
Dec 10, 2012, 9:48:53 AM12/10/12
to
On 2012-12-10 12:33:15 +0000, MG said:
> On 10-dec-2012 3:38, Steven Schweda wrote:
>
>
>> I can guess all kinds of things, but my time is apparently
>> more valuable to me than it is to you.
>
> Nowadays it's quite clear what HP provides through the Hobbyist
> Program, is what I meant. (Assuming you're a partaker, like me,
> as well.)
The Hobbyist Program goals are the same as they always have been,
> On 10-dec-2012 3:38, Steven Schweda wrote:
>
>
>> I can guess all kinds of things, but my time is apparently
>> more valuable to me than it is to you.
>
> Nowadays it's quite clear what HP provides through the Hobbyist
> Program, is what I meant. (Assuming you're a partaker, like me,
> as well.)
AFAIK. Access for interested (non-commercial) users to become familiar
with using and managing and programming on OpenVMS. AFAIK, the program
has never been intended for production use, nor for commercial
development use.
> More importantly, I wasn't demanding your help. I wasn't asking
> for help at all, I'm not 'troubleshooting' or trying to 'fix' a
> specific thing (as I already stated in my previous reply).
assistance (albeit with a dearth of details), followed by a complaint.
Which is a posting format following a pattern that is not unfamiliar to
the readers of comp.os.vms. FWIW.
> I'm just trying to 'poll', openly wondering if people are as
> 'satisfied' as I am about the points I brought up.
are the particular questions you're looking to have answered?
Is the OpenVMS IP network stack...
...known to perform slower than the IP stack found on various Linux
distros? Yes.
...receiving features and enhancements less frequently than other
operating systems? Yes.
...management user interface arcane, and with comparatively primitive
configuration and management interfaces? Yes.
...known for occasional gremlins when interoperating with other random
IP stacks? Yes. (What IP stack isn't?)
...functional, stable and with the performance necessary for the tasks
it's usually used for? Yes.
The above answers are application-dependent, and your mileage and
requirements and perceptions may vary.
OpenVMS is a specialized and purpose-installed operating system, and
most commonly used in recent years as a component of an embedded
application-specific server-related requirement.
Can OpenVMS be used for other and more general activities? Sure. But
it does tend toward being awkward for these other tasks, and
increasingly requiring manual management or add-on tools or editing
configuration files or such.
AFAIK, OpenVMS is not sold as nor packaged as a general-purpose
operating system, and it's definitely not suited for nor packaged as a
desktop-replacement, nor is it commonly used as a server for (for
instance) SMTP mail, authentication or DNS services. While OpenVMS
can be used for those tasks, most places will choose and use different
servers for those tasks; Linux or BSD or Windows Server boxes, for
instance.
OpenVMS works for what most folks want and use it for (and often quite
well), but it's not known for featuring advanced or bleeding-edge
capabilities and features.
--
Pure Personal Opinion | HoffmanLabs LLC
Steven Schweda
Dec 10, 2012, 9:53:08 AM12/10/12
to Steven M. Schweda
> Not just bad, terrible bad? [...]
Trying to make fun of people for whom English is a second
language is another good way to discourage helpful responses.
(If you needed one.)
> [...] Maybe you can try to use your imagination? [...]
That works for me. And perhaps you can imagine that you
got some useful responses.
> Have fun!
Seconded.
Trying to make fun of people for whom English is a second
language is another good way to discourage helpful responses.
(If you needed one.)
> [...] Maybe you can try to use your imagination? [...]
That works for me. And perhaps you can imagine that you
got some useful responses.
> Have fun!
Seconded.
MG
Dec 10, 2012, 10:00:51 AM12/10/12
to
On 10-dec-2012 15:48, Stephen Hoffman wrote:
> The Hobbyist Program goals are the same as they always have been,
> AFAIK. Access for interested (non-commercial) users to become familiar
> with using and managing and programming on OpenVMS. AFAIK, the program
> has never been intended for production use, nor for commercial
> development use.
Sorry, but are you trying to make a point?
> The Hobbyist Program goals are the same as they always have been,
> AFAIK. Access for interested (non-commercial) users to become familiar
> with using and managing and programming on OpenVMS. AFAIK, the program
> has never been intended for production use, nor for commercial
> development use.
> Whether intended or not, your posting did read like a request for
> assistance (albeit with a dearth of details), followed by a complaint.
> Which is a posting format following a pattern that is not unfamiliar
> to the readers of comp.os.vms. FWIW.
Thanks in advance.
> AFAIK, OpenVMS is not sold as nor packaged as a general-purpose
> operating system
transcript of that HP Discover presentation... (Not to mention
HP's willingness.)
> and it's definitely not suited for nor packaged as a
> desktop-replacement, nor is it commonly used as a server for
> (for instance) SMTP mail, authentication or DNS services.
mention those things in this thread.
- MG
MG
Dec 10, 2012, 10:04:28 AM12/10/12
to
On 10-dec-2012 15:53, Steven Schweda wrote:
> Trying to make fun of people for whom English is a second
> language is another good way to discourage helpful responses.
> (If you needed one.)
English isn't my first language either, nice try though. Also,
> Trying to make fun of people for whom English is a second
> language is another good way to discourage helpful responses.
> (If you needed one.)
for the umpteenth time, I'm not looking for 'help'. How many
times do I need to keep repeating this before it finally sinks
in?
- MG
Jan-Erik Soderholm
Dec 10, 2012, 11:24:53 AM12/10/12
to
MG wrote 2012-12-10 16:00:
> On 10-dec-2012 15:48, Stephen Hoffman wrote:
>> The Hobbyist Program goals are the same as they always have been,
>> AFAIK. Access for interested (non-commercial) users to become familiar
>> with using and managing and programming on OpenVMS. AFAIK, the program
>> has never been intended for production use, nor for commercial
>> development use.
>
> Sorry, but are you trying to make a point?
>
>
>> Whether intended or not, your posting did read like a request for
>> assistance (albeit with a dearth of details), followed by a complaint.
>> Which is a posting format following a pattern that is not unfamiliar
>> to the readers of comp.os.vms. FWIW.
>
> Could you point me to the parts where I was 'requesting' 'assistance'?
>
It's (was) the general interpretation, it seems.
> On 10-dec-2012 15:48, Stephen Hoffman wrote:
>> The Hobbyist Program goals are the same as they always have been,
>> AFAIK. Access for interested (non-commercial) users to become familiar
>> with using and managing and programming on OpenVMS. AFAIK, the program
>> has never been intended for production use, nor for commercial
>> development use.
>
> Sorry, but are you trying to make a point?
>
>
>> Whether intended or not, your posting did read like a request for
>> assistance (albeit with a dearth of details), followed by a complaint.
>> Which is a posting format following a pattern that is not unfamiliar
>> to the readers of comp.os.vms. FWIW.
>
> Could you point me to the parts where I was 'requesting' 'assistance'?
>
And it is also the usualy reason to post here.
>
> I'm surprised it's sold at all, especially after reading that
> transcript of that HP Discover presentation... (Not to mention
> HP's willingness.)
They know perfectly well what they want anyway.
As the times are, I find it positive that VMS was mentioned at all.
David Froble
Dec 10, 2012, 1:35:16 PM12/10/12
to
As for the network transmission speed of VMS TCP/IP, I don't know why it
should be so much slower than other environments. It's usually similar
networking hardware.
If you're talking older DEC gear, perhaps the disk performance is involved.
If you're talking VMS, incoming data gets written to disk, not just
cached up in memory. Outgoing data I would assume gets read from disk.
Not that I get out much, but I doubt many are running VMS to move GB of
data over the network. If it's limited usually to short messages, total
throughput is less than a minor concern.
It would be interesting to know why VMS TCP/IP moves network traffic
slower than other environments. Inquiring minds want to know ....
David Froble
Dec 10, 2012, 1:49:51 PM12/10/12
to
being precise on what you're asking, and why, is not only useful, but
polite.
Someone might infer from a poorly asked question that you're have some
difficulty on a production related issue, and devote significant time to
attempt to help you with a real problem. It's not very nice to cause
them to devote valuable time to something when it's just a matter of
curiosity.
Yes, there are people on c.o.v who will put time into trying to help
others. One of the nice things about the newsgroup.
When you do have a problem, it's best to state the problem and what
you're trying to do. Yes, you can ask about what you perceive as the
resolution path, but you may be going in an unhelpful direction. By
stating what you're trying to do, others can then provide solutions that
have worked, which may be totally different than what you may think is a
valid solution.
So:
1) it's polite to state whether a post is about a problem, or curiosity
2) if a problem, providing sufficient data for other to understand the
problem is helpful
Stephen Hoffman
Dec 10, 2012, 1:50:56 PM12/10/12
to
On 2012-12-10 18:35:16 +0000, David Froble said:
> It would be interesting to know why VMS TCP/IP moves network traffic
> slower than other environments. Inquiring minds want to know ....
At a high altitude: too many block copies, and too many context switches.
> It would be interesting to know why VMS TCP/IP moves network traffic
> slower than other environments. Inquiring minds want to know ....
Some of the Linux developers have been making a non-trivial effort to
streamline their I/O code, and it's paid off.
MG
Dec 10, 2012, 2:13:52 PM12/10/12
to
On 10-dec-2012 19:49, David Froble wrote:
> Someone might infer from a poorly asked question that you're have some
> difficulty on a production related issue, and devote significant time to
> attempt to help you with a real problem. It's not very nice to cause
> them to devote valuable time to something when it's just a matter of
> curiosity.
People with commercial interests shouldn't be here in the first place.
> Someone might infer from a poorly asked question that you're have some
> difficulty on a production related issue, and devote significant time to
> attempt to help you with a real problem. It's not very nice to cause
> them to devote valuable time to something when it's just a matter of
> curiosity.
Actually, that's quite lamentable if you ask me. (Aren't commercial
users paying HP good money for their so-called support?!) A bit of a
cheapskate mentality, to then use the Usenet as an 'helpdesk'.
Again, I wasn't asking, requesting or remotely insinuating a need for
help or assistance, whatsoever. I already pointed this out, several
times. If you think I were, please cite me the parts where I was
allegedly 'asking'/'requesting'/etc. for 'assistance' or 'help'.
> Yes, there are people on c.o.v who will put time into trying to help
> others. One of the nice things about the newsgroup.
care much for the help provided here and if I do, it's usually my
last resort. I don't always feel like sharing all my system
configuration with the entire world, because some need to have
everything spelled out.
But, once more, I wasn't asking for help! When, oh when, will this
finally sink in?
> 1) it's polite to state whether a post is about a problem, or curiosity
- MG
Stephen Hoffman
Dec 10, 2012, 2:37:11 PM12/10/12
to
On 2012-12-10 19:13:52 +0000, MG said:
> On 10-dec-2012 19:49, David Froble wrote:
>> Someone might infer from a poorly asked question that you're have some
>> difficulty on a production related issue, and devote significant time to
>> attempt to help you with a real problem. It's not very nice to cause
>> them to devote valuable time to something when it's just a matter of
>> curiosity.
>
> People with commercial interests shouldn't be here in the first place.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
I'd wager that most of the folks posting and lurking in c.o.v. are
> On 10-dec-2012 19:49, David Froble wrote:
>> Someone might infer from a poorly asked question that you're have some
>> difficulty on a production related issue, and devote significant time to
>> attempt to help you with a real problem. It's not very nice to cause
>> them to devote valuable time to something when it's just a matter of
>> curiosity.
>
> People with commercial interests shouldn't be here in the first place.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
commercial sites, or have commercial interests involving OpenVMS.
AFAIK, most of the folks posting in this current thread have commercial
interests involving OpenVMS.
Simon Clubley
Dec 10, 2012, 3:10:57 PM12/10/12
to
On 2012-12-10, MG <marc...@SPAMxs4all.nl> wrote:
> On 10-dec-2012 19:49, David Froble wrote:
>> Someone might infer from a poorly asked question that you're have some
>> difficulty on a production related issue, and devote significant time to
>> attempt to help you with a real problem. It's not very nice to cause
>> them to devote valuable time to something when it's just a matter of
>> curiosity.
>
> People with commercial interests shouldn't be here in the first place.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
>
I'm sorry, but you are way, way off base here. :-( :-(
> On 10-dec-2012 19:49, David Froble wrote:
>> Someone might infer from a poorly asked question that you're have some
>> difficulty on a production related issue, and devote significant time to
>> attempt to help you with a real problem. It's not very nice to cause
>> them to devote valuable time to something when it's just a matter of
>> curiosity.
>
> People with commercial interests shouldn't be here in the first place.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
>
In my day job, I am a commercial user and I pay for support as well.
When HP come back to me (or someone else here) with a useless response,
this place, which is full of fellow professionals, acts as a sanity
check as well as a source of advice. People can also supply data points
which can then be taken back to HP.
On a personal note, look at the major issues I had with that sodding
pile of junk known as the sftp client earlier on this year. On a
newsgroup wide note, look at how we were able to come to a consensus
on the state of VMS patches by sharing our own individual experiences.
There's nothing "cheapskate" about interacting in this newsgroup. :-(
You have made me annoyed with your response.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
Dec 10, 2012, 3:31:30 PM12/10/12
to
On 2012-12-10 20:10:57 +0000, Simon Clubley said:
>
> You have made me annoyed with your response.
>
Try saying that with the Marvin the Martian voice, and add a reference
>
> You have made me annoyed with your response.
>
to the Illudium Q-36 Explosive Space Modulator. :-)
Jan-Erik Soderholm
Dec 10, 2012, 3:53:25 PM12/10/12
to
MG wrote 2012-12-10 20:13:
> People with commercial interests shouldn't be here in the first place.
That was realy dumb.
> People with commercial interests shouldn't be here in the first place.
I make my living from VMS. Has done for 25 years and plan
to retire that way in 5-6 years.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
Of course, and we use that if we realy have a VMS related problem.
We (or my customer) also pays support for Oracle Rdb, but
I'm still a member of the rdblist mail-list. Go figure...
> Again, I wasn't asking, requesting or remotely insinuating a need for
> help or assistance, whatsoever.
> I rarely ask for help here, to begin with. To be honest, I don't
Right, fine. Good luck.
Simon Clubley
Dec 10, 2012, 4:01:00 PM12/10/12
to
On 2012-12-10, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2012-12-10 20:10:57 +0000, Simon Clubley said:
>>
>> You have made me annoyed with your response.
>>
>
> Try saying that with the Marvin the Martian voice, and add a reference
> to the Illudium Q-36 Explosive Space Modulator. :-)
>
:-)
> On 2012-12-10 20:10:57 +0000, Simon Clubley said:
>>
>> You have made me annoyed with your response.
>>
>
> Try saying that with the Marvin the Martian voice, and add a reference
> to the Illudium Q-36 Explosive Space Modulator. :-)
>
Ok, I'm less annoyed now. :-)
To MG:
Usenet has been around for 30 years now and I've been using it for the
last 20 years. One of the common factors over all that time has been
the ability of people of shared interests to talk to one another, share
ideas/experiences and be exposed to concepts they may never have realised
on their own.
People of all experiences and skill levels interact together across
these newsgroups without regard for whether someone is or is not a
"commercial" or professional person in that area of interest and
everyone is better off as a result.
comp.os.vms is exactly the kind of place Usenet is all about.
John Wallace
Dec 10, 2012, 4:51:07 PM12/10/12
to
impact on the observed behaviour. Once upon a time, there was
something called TCP SLOW START. Everybody's TCP stack had it
(mostly), but they didn't all play nice together, and in some
circumstances the observed TCP-layer throughput for a noddy
application pair where one end sends and the other end receives and
discards could be significantly lower than intuition might suggest.
dslreports used to have a nice writeup but it fell off the Internet.
Others are doubtless available.
Anyway, a pair of apps communicating with suboptimal slow start
settings would not benefit from RMS tuning or that kind of thing,
because the transport layer is the limiting factor. First, make sure
the box-to-box transport is working as well as it can. *Then* look at
the next layer(s) up.
Not 100% sure if that is still relevant in the era of GbE and jumbo
frames and all that jazz. But it used to be.
johnso...@gmail.com
Dec 10, 2012, 7:16:37 PM12/10/12
to
> It would be interesting to know why VMS
> TCP/IP moves network traffic slower than
> other environments. Inquiring minds want to
> know ....
I'd like to provide some insight here as I spent
> TCP/IP moves network traffic slower than
> other environments. Inquiring minds want to
> know ....
a good chunk of time looking into this very issue.
I think it's best to look at the performance gap
through the eyes of UDP rather than TCP as
TCP has a number of well intended knobs and
and auto adjustments that complicate the
analysis.
One way to do the comparison is to write a
small program that sends 100 byte UDP packets.
And then perform that send in a tight loop. With
UDP there is no buffering. When you call send,
It is sent or at least given to the NIC.
When you run that program in a tight loop on
Linux on semi modern hardware, you will find
that the cost of traveling down into the kernel
and back is a couple of microseconds. If you
try the same on VMS, you will wait at least 50
microseconds.
I'm assuming 1Gbe pipe and I'll be quoting
times in microseconds. NOT milliseconds.
If you look at the raw output on your Linux box
with tcpdump you will see the packets streaming
out every few microseconds.
The results on VMS are disappointing.
One could point a finger at the sockets API
itself and assert that it's a foreigner that has
caused the latency. I had rewritten that code
into its SYS$ equivalent and found some
improvement but no where near the Linux
performance.
This suggests a deep problem within the stack.
Most of my testing was done with multinet, but
I found that TCP/IP services didn't change the
landscape too much.
The question persisted - why do the IP stacks
struggle to send. Is receive better?
The answer here is the same. I tried a simple
UDP ping pong test. I tried Linux to Linux,
VMS to Linux, and VMS to VMS. The slowest
tennis match was VMS at both ends. I could
only bounce a small packet back and forth with
a round trip of 200us at best. This is in a modern
data center environment. Linux to Linux? Sub
90us.
So why are the IP stacks so slow? Is it inside of
them or is it something deeper?
So I learned how the IP stacks do their stuff. They use a kernel mode API known as VCI. That was lovingly documented in April 1993 and
there is a random web site that has it all as an
old school vms HTML help. It's very nice.
The API enables one to receive a specific
Ethernet type and to send a specific Ethernet
type. I wrote a small UDP handler to push
packets to another process.
At this level of the system, I would say VCI
is pretty good. The receive handler would take
in the Ethernet frame in interrupt mode and
shuffle it off to another process. I found that
could be done in about 8 microseconds on
an rx8640. Decent. I suspect the C
compiler didn't produce the best ia64 code.
A surprising amount of that time was lost
in a call to $wake and getting the SCHED
spinlock. Must be something about the ia64
that makes that costly.
Sending was decent. I remember having a bug
in my first go around and utterly hammered on
the sending and drew the ire of local network
admins as they hunted me down for drowning
their network. About the only time a vms box
ever did that!
When I did my udp ping pong between Linux
and VMS, the round trip time that was once 200,
finally bested Linux. I could hit 70us.
I found that the key to this was to not mess
around with complex structures or any locks
that weren't really needed. I bet the existing
stacks have a lot of code and legacy structs
that make that quite hard.
My assessment. The IP stacks are inefficient
at basic Ethernet frame handling and have
significant contention around core spinlocks
that hinder real performance. The inadequate
compiler situation and the general lackluster
performance of itanium in these situations
isn't a help either.
EJ
MG
Dec 10, 2012, 7:20:48 PM12/10/12
to
On 10-dec-2012 21:10, Simon Clubley wrote:
> When HP come back to me (or someone else here) with a useless response,
> this place, which is full of fellow professionals, acts as a sanity
> check as well as a source of advice. People can also supply data points
> which can then be taken back to HP.
You're not trying to understand me. If you can't bother to read the
> When HP come back to me (or someone else here) with a useless response,
> this place, which is full of fellow professionals, acts as a sanity
> check as well as a source of advice. People can also supply data points
> which can then be taken back to HP.
full thread and understand the full context, then that's your problem.
I was talking, or replying, to people who were accusing me of my
supposed unwillingness to provide information to be helped (help or
assistance I never asked for, certainly not in this thread).
> On a personal note, look at the major issues I had with that sodding
> pile of junk known as the sftp client earlier on this year. On a
> newsgroup wide note, look at how we were able to come to a consensus
> on the state of VMS patches by sharing our own individual experiences.
newsgroups function as a 'sanity check', then I don't want to know what
you ordinarily deal with...
> There's nothing "cheapskate" about interacting in this newsgroup. :-(
>
> You have made me annoyed with your response.
you naturally shouldn't feel addressed. I think that's not very hard
to understand, now is it?
Whether I annoy or not is entirely your own problem, you wouldn't
know the amount of times I'm annoyed by things I real. Deal with
it.
- MG
MG
Dec 10, 2012, 7:24:30 PM12/10/12
to
On 10-dec-2012 21:53, Jan-Erik Soderholm wrote:
>> People with commercial interests shouldn't be here in the
>> firstplace.
>
> That was realy dumb.
Just like consistently spelling realLy with one /L/?
>> People with commercial interests shouldn't be here in the
>> firstplace.
>
> That was realy dumb.
> I make my living from VMS. Has done for 25 years and plan
> to retire that way in 5-6 years.
discussed in this thread?
>> Actually, that's quite lamentable if you ask me. (Aren't
>> commercial users paying HP good money for their so-called
>> support?!)...
>
> Of course, and we use that if we realy have a VMS related
> problem.
place?
>> Again, I wasn't asking, requesting or remotely insinuating a
>> need for help or assistance, whatsoever.
>
> You seem to be alone with that opinion.
understand this difference?
>> I rarely ask for help here, to begin with. To be honest, I
>> don't care much for the help provided here.....
>
> Right, fine. Good luck.
- MG
MG
Dec 10, 2012, 7:27:00 PM12/10/12
to
On 11-dec-2012 1:20, MG wrote:
> Whether I annoy or not is entirely your own problem, you wouldn't
> know the amount of times I'm annoyed by things I real.
*read
> Whether I annoy or not is entirely your own problem, you wouldn't
> know the amount of times I'm annoyed by things I real.
- MG
MG
Dec 10, 2012, 7:33:14 PM12/10/12
to
On 10-dec-2012 22:51, John Wallace wrote:
> [...]
are GbE and 10GbE, I barely even deal with anything below (other than
things like iLO/MP and the like interfaces, where maximized throughput
isn't of importance).
- MG
> [...]
>
> Not 100% sure if that is still relevant in the era of GbE and jumbo
> frames and all that jazz. But it used to be.
That's certainly what surprises me, too. In fact, nearly all my NICs
> Not 100% sure if that is still relevant in the era of GbE and jumbo
> frames and all that jazz. But it used to be.
are GbE and 10GbE, I barely even deal with anything below (other than
things like iLO/MP and the like interfaces, where maximized throughput
isn't of importance).
- MG
MG
Dec 10, 2012, 7:42:17 PM12/10/12
to
On 11-dec-2012 1:16, johnso...@gmail.com wrote:
> I'd like to provide some insight here as I spent
> a good chunk of time looking into this very issue.
Thank you for your input, at least some people got the
> I'd like to provide some insight here as I spent
> a good chunk of time looking into this very issue.
purpose of this thread.
> I think it's best to look at the performance gap
> through the eyes of UDP rather than TCP as
> TCP has a number of well intended knobs and
> and auto adjustments that complicate the
> analysis.
indeed look into the UDP side of things or more closely.
> When you run that program in a tight loop on
> Linux on semi modern hardware, you will find
> that the cost of traveling down into the kernel
> and back is a couple of microseconds. If you
> try the same on VMS, you will wait at least 50
> microseconds.
> The results on VMS are disappointing.
> This suggests a deep problem within the stack.
> Most of my testing was done with multinet, but
> I found that TCP/IP services didn't change the
> landscape too much.
at the previous paragraph), it is interesting that you tested
two major stacks; especially for the sake of comparison.
> The answer here is the same. I tried a simple
> UDP ping pong test. I tried Linux to Linux,
> VMS to Linux, and VMS to VMS. The slowest
> tennis match was VMS at both ends. I could
> only bounce a small packet back and forth with
> a round trip of 200us at best. This is in a modern
> data center environment. Linux to Linux? Sub
> 90us.
> So why are the IP stacks so slow? Is it inside of
> them or is it something deeper?
>
> So I learned how the IP stacks do their stuff. They
> use a kernel mode API known as VCI. That was lovingly
> documented in April 1993 and there is a random web
> site that has it all as an old school vms HTML help.
> It's very nice.
> At this level of the system, I would say VCI
> is pretty good. The receive handler would take
> in the Ethernet frame in interrupt mode and
> shuffle it off to another process. I found that
> could be done in about 8 microseconds on
> an rx8640. Decent. I suspect the C compiler
> didn't produce the best ia64 code.
recall that?)
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
recent EV68CB system from 2007~'08, like a DS15 --- has sadly
not been that phenomenal either though...
Thank you again for the input, it was a great read.
- MG
MG
Dec 10, 2012, 7:52:44 PM12/10/12
to
On 10-dec-2012 22:01, Simon Clubley wrote:
> To MG:
>
> Usenet has been around for 30 years now and I've been using it for the
> last 20 years. One of the common factors over all that time has been
> the ability of people of shared interests to talk to one another, share
> ideas/experiences and be exposed to concepts they may never have realised
> on their own.
Guess what I tried to do? However, did you see the first few replies?
> To MG:
>
> Usenet has been around for 30 years now and I've been using it for the
> last 20 years. One of the common factors over all that time has been
> the ability of people of shared interests to talk to one another, share
> ideas/experiences and be exposed to concepts they may never have realised
> on their own.
I wouldn't dare to describe them as sociopathic, but some just might.
> People of all experiences and skill levels interact together across
> these newsgroups without regard for whether someone is or is not a
> "commercial" or professional person in that area of interest and
> everyone is better off as a result.
being so intensely focused on it that they occasionally tend to
forget what some threads are about.
As this thread shows once more, there's certainly no so-called sharing
of ideas/experiences. Unless you consider the prevalent 'RTFM'-esque
rhetoric that...
> comp.os.vms is exactly the kind of place Usenet is all about.
places... That is, if you aren't looking for spam.
- MG
David Froble
Dec 10, 2012, 9:00:06 PM12/10/12
to
But you know that you opened up a can of worms, don't you?
The first question that occurs to me is, ... are the techniques at the
core of VMS a performance issue? I'm aware that somewhere there needs
to be an arbiter of who can do what, nor am I aware of any better
methods that what's in VMS. The caviet is, as most know, I don't get
out much.
David Froble
Dec 10, 2012, 9:06:39 PM12/10/12
to
Your definition of "constantly" is interesting, or, were there other
posts you were referring to?
Steven Underwood
Dec 10, 2012, 9:29:41 PM12/10/12
to
"MG" wrote in message
news:50c5d68d$0$3097$e4fe...@dreader34.news.xs4all.nl...
>I'm just trying to 'poll', openly wondering if people are as
>'satisfied' as I am about the points I brought up.
>
I am more than satisfied with the speed of FTP on VMS.
Steven Underwood
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Arne Vajhøj
Dec 10, 2012, 10:08:59 PM12/10/12
to
On 12/10/2012 7:16 PM, johnso...@gmail.com wrote:
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
A lot of that is really symptoms of too little
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
money having been invested in development.
Arne
Arne Vajhøj
Dec 10, 2012, 10:11:55 PM12/10/12
to
On 12/10/2012 7:24 PM, MG wrote:
> On 10-dec-2012 21:53, Jan-Erik Soderholm wrote:
>>> People with commercial interests shouldn't be here in the
>>> firstplace.
>>
>> That was realy dumb.
>
> Just like consistently spelling realLy with one /L/?
How good is your Swedish?
> On 10-dec-2012 21:53, Jan-Erik Soderholm wrote:
>>> People with commercial interests shouldn't be here in the
>>> firstplace.
>>
>> That was realy dumb.
>
> Just like consistently spelling realLy with one /L/?
>> I make my living from VMS. Has done for 25 years and plan
>> to retire that way in 5-6 years.
>
> So what? What does that have to do with anything recently
> discussed in this thread?
Arne
Steven Schweda
Dec 11, 2012, 1:05:04 AM12/11/12
to Steven M. Schweda
On Dec 10, 9:04 am, MG <marcog...@SPAMxs4all.nl> wrote:
> On 10-dec-2012 15:53, Steven Schweda wrote:
>
> > Trying to make fun of people for whom English is a second
> > language is another good way to discourage helpful responses.
> > (If you needed one.)
>
> English isn't my first language either, [...]
> On 10-dec-2012 15:53, Steven Schweda wrote:
>
> > Trying to make fun of people for whom English is a second
> > language is another good way to discourage helpful responses.
> > (If you needed one.)
>
Not really a relevant fact, is it?
> Also,
> for the umpteenth time, I'm not looking for 'help'. How many
> times do I need to keep repeating this before it finally sinks
> in?
the following should be just what you seek.
system1# time cp -p alp/unzip610c08a_l_sH.zip .
real 0m12.092s
user 0m0.000s
sys 0m0.012s
system1# ls -l unzip610c08a_l_sH.zip
-rwxr-x--- 1 root root 3273071 Dec 10 21:35 unzip610c08a_l_sH.zip
system1# uname -a
[You don't really need to know everything. Some things are private.]
system2# time cp -p alp/unzip610c08a_l_sH.zip .
real 0m0.986s
user 0m0.000s
sys 0m0.010s
system2# ls -l unzip610c08a_l_sH.zip
-rwxr-x--- 1 root root 3273071 Dec 10 2012
unzip610c08a_l_sH.zip
system2# uname -a
[You don't really need to know everything. Some things are private.]
Apparently, some of the insignificant properties of the NFS
client can make some difference in the transfer speed from a
VMS server (of some type or other).
Paul Sture
Dec 11, 2012, 2:37:10 AM12/11/12
to
In article <d31640f8-a555-45ca...@googlegroups.com>,
johnso...@gmail.com wrote:
Good stuff snipped for brevity
> When I did my udp ping pong between Linux
> and VMS, the round trip time that was once 200,
> finally bested Linux. I could hit 70us.
>
> I found that the key to this was to not mess
> around with complex structures or any locks
> that weren't really needed. I bet the existing
> stacks have a lot of code and legacy structs
> that make that quite hard.
>
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
In a test I did several years ago, I also found that receiving on the
VMS side could be slowed down by using the default file extend quantity
of VMS. Upping that got me a decent performance increase, though I must
add this was on an oldish Alpha with internal disks.
--
Paul Sture
Q: pleasecanyoufixmyspacebar?
A: myspaceisdeadyouneedtotryfacebook
johnso...@gmail.com wrote:
Good stuff snipped for brevity
> When I did my udp ping pong between Linux
> and VMS, the round trip time that was once 200,
> finally bested Linux. I could hit 70us.
>
> I found that the key to this was to not mess
> around with complex structures or any locks
> that weren't really needed. I bet the existing
> stacks have a lot of code and legacy structs
> that make that quite hard.
>
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
VMS side could be slowed down by using the default file extend quantity
of VMS. Upping that got me a decent performance increase, though I must
add this was on an oldish Alpha with internal disks.
--
Paul Sture
Q: pleasecanyoufixmyspacebar?
A: myspaceisdeadyouneedtotryfacebook
Michael Kraemer
Dec 11, 2012, 2:54:23 AM12/11/12
to
johnso...@gmail.com schrieb:
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
So the gist of all that is:
it's the spin lock, stupid?
The question arises: why does VMS use such
an inefficient mechanism, whereas the
Unixoids don't? Wouldn't it be better
to use one of those indivisable instructions
(compare-and-swap, test-and-set) instead?
> My assessment. The IP stacks are inefficient
> at basic Ethernet frame handling and have
> significant contention around core spinlocks
> that hinder real performance. The inadequate
> compiler situation and the general lackluster
> performance of itanium in these situations
> isn't a help either.
it's the spin lock, stupid?
The question arises: why does VMS use such
an inefficient mechanism, whereas the
Unixoids don't? Wouldn't it be better
to use one of those indivisable instructions
(compare-and-swap, test-and-set) instead?
Paul Sture
Dec 11, 2012, 3:14:14 AM12/11/12
to
In article <ka4qe3$hnp$1...@news.albasani.net>,
Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> MG wrote 2012-12-10 14:13:
>
> > The DECnet performance (or lack thereof), as far as your
> > experience goes with it.
> >
>
> DECnet is a bit like VMS itself, it has a number of
> nice features (for DECnet the main one is the integration
> with VMS, of course), but raw speed has never been one
> of them.
>
> But again, it was/is usualy "good enough". That some other
> plattform might clock a higher raw speed doesn't say that the
> speed of VMS, DECnet or TCPIP/Services isn't "good enough".
Now that you mention it, VMS sites I worked on where large file
transfers were routine were usually talking to non-VMS machines with a
combination of specialist hardware and software. SNA for IBM
mainframes, HYPERchannel and similar products for other systems.
Some of these products were wicked fast for the time.
> What is you actual application where the current speed of
> whatever-you-are-doing isn't good enough ?
>
My guess would be benchmarks out of curiosity rather than commercial
production work.
You can quickly end up down a rat hole when doing benchmarks.
Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> MG wrote 2012-12-10 14:13:
>
> > The DECnet performance (or lack thereof), as far as your
> > experience goes with it.
> >
>
> DECnet is a bit like VMS itself, it has a number of
> nice features (for DECnet the main one is the integration
> with VMS, of course), but raw speed has never been one
> of them.
>
> But again, it was/is usualy "good enough". That some other
> plattform might clock a higher raw speed doesn't say that the
> speed of VMS, DECnet or TCPIP/Services isn't "good enough".
Now that you mention it, VMS sites I worked on where large file
transfers were routine were usually talking to non-VMS machines with a
combination of specialist hardware and software. SNA for IBM
mainframes, HYPERchannel and similar products for other systems.
Some of these products were wicked fast for the time.
> What is you actual application where the current speed of
> whatever-you-are-doing isn't good enough ?
>
My guess would be benchmarks out of curiosity rather than commercial
production work.
You can quickly end up down a rat hole when doing benchmarks.
johnso...@gmail.com
Dec 11, 2012, 6:47:28 AM12/11/12
to
On Monday, December 10, 2012 7:42:17 PM UTC-5, MG wrote:
>> So I learned how the IP stacks do their stuff. They
>> use a kernel mode API known as VCI. That was lovingly
>> documented in April 1993 and there is a random web
>> site that has it all as an old school vms HTML help.
>> It's very nice.
>
> Fascinating. Thank you, I will definitely look into that!
The VCI API documentation can be found here.
>> So I learned how the IP stacks do their stuff. They
>> use a kernel mode API known as VCI. That was lovingly
>> documented in April 1993 and there is a random web
>> site that has it all as an old school vms HTML help.
>> It's very nice.
>
> Fascinating. Thank you, I will definitely look into that!
http://starlet.deltatel.ru/vci1.html
The Digital employee that wrote that documentation clearly cared
about the API. That manual was a labor of love. It's quite detailed
and incredibly accurate. Not bad for something that was written
nearly 20 years ago! I owe that an employee some beer. I could
never have written what I did without that documentation.
>> At this level of the system, I would say VCI
>> is pretty good. The receive handler would take
>> in the Ethernet frame in interrupt mode and
>> shuffle it off to another process. I found that
>> could be done in about 8 microseconds on
>> an rx8640. Decent. I suspect the C compiler
>> didn't produce the best ia64 code.
> What kind of optimizations did you attempt?
Itanium so the optimization choices were aimed at those needs.
So some of what I will describe will seem like its not useful
for a generalized usage pattern.
In this case, the application was going to exchange only one
UDP packet in a request/response fashion. While there would
be more than one instance of the application at a time, each one
would have a monogamous relationship with its Linux based buddy.
And the linux based process was going to be in the driver's seat
with the VMS host process acting as responsive slave. So one
process to one process. One request. One reply.
VCI takes an ethernet frame and presents it in the form of a
VCRP to the receive function that you provide. It is the responsibility
of that function to then deallocate that VCRP.
The deallocation requires taking out IOLOCK8. In looking at the
performance, I had wondered if there was value to bunching up
those frees. Let the receive function accumulate a few (8?)
and then do the free en masse. You can't leak those VCRPs as
they are quite precious.
But in my case, I was going to receive a steady stream of them.
The cost of freeing them might be cheaper when amortized out in
that fashion. Especially since acquiring IOLOCK8 seemed expensive
compared to the free.
In my case, there's also the issue of harvesting the bytes from the
VCRP. At times, it looked like the memcpy out of the VCRP was expensive.
So I had played with transferring that responsibility to the receiving
process. I would keep the VCRP, poke the process with $wake, and then
let the receiving process harvest the bytes and free the VCRP through
the API I provided to the IP stack.
This reduced the amount of time spent in the receive function which
frees it up to process another packet. But if the receiving VMS process
went away or was unresponsive, you would leak the VCRP unless one had
another mechanism in place to harvest those.
I think part of my issue was caused by working with a 10 GigE card in a
PCI-X slot. So copying large amounts of data on and off that card was
relatively expensive. Placing the card in a PCI Express v2 slot would
have been a better choice, but that wasn't a possibility for me at
the time.
My whole line of thinking is that the receive function is a game of hot
potato. Get in, get out, and STFU. Any farting around in the receive
function can't be tolerated. It backs up everything. Every line of code
has to be defended or it goes. There may be a million microseconds in
a second, but everyone of them is precious and you have to care about
each one. Don't waste them.
My sending side seemed to be pretty pokey at times, but the corporate
support for the project evaporated before I could really dig in.
I felt that the C code to compute the IP header checksum was slower than
I expected. Macro-32 might do better in this area.
I spent some time making sure I had VCRPs pre-created prior to sending.
Since I would only send at most one UDP packet at a time, I could get away
with that given the target application.
I skipped checking the IP header checksum as I recall. Again, the target
usage was a data center application. The idea that the packet is damaged
in transit in that environment seemed absurd to me.
And because I was using IP v4, I could opt out of the data checksum is
optional in that case. Computing that checksum for 64k worth of data
seemed awfully expensive and not necessary given modern environments.
Again, a Macro32 implementation might be better for itanium than C.
IP fragmentation is painful when doing the send side. In that sense,
jumbo frames can be a huge win. You can go from 40 sends to 9. Fewer
VCRPs to manage, and less overhead in total
You can find some example VCI code in an old VMS freeware CD. I think
it was v5 or v6 that had a working pcapvcm.c/vci_jacket.mar for the tcpdump
utility. That one came in two flavors. One that used SYS$QIO and the
other did VCI. I believe they have a few bugs in their VCI usage which
caused crashes and that code was ultimately pulled. If you are good with
the great google, you can find it.
Hope that helps a bit.
EJ
MG
Dec 11, 2012, 7:26:18 AM12/11/12
to
On 11-dec-2012 7:05, Steven Schweda wrote:
> Not really a relevant fact, is it?
No? Well, didn't you bring it up?
> Not really a relevant fact, is it?
> Ok. If you're not looking for a helpful response, then
> the following should be just what you seek.
- MG
MG
Dec 11, 2012, 7:27:55 AM12/11/12
to
On 11-dec-2012 3:06, David Froble wrote:
> Your definition of "constantly" is interesting, or, were there
> other posts you were referring to?
Some are kind of 'preachy' here. Although, that's something
> Your definition of "constantly" is interesting, or, were there
> other posts you were referring to?
many with 'computing' backgrounds seem to suffer from and
often act as if they invented 'the computer'...
- MG
MG
Dec 11, 2012, 7:29:31 AM12/11/12
to
On 11-dec-2012 4:11, Arne Vajh�j wrote:
> How good is your Swedish?
Why, did I recently misspell something in Swedish whilst,
> How good is your Swedish?
repeatedly, calling someone 'dumb'?
- MG
Simon Clubley
Dec 11, 2012, 7:41:23 AM12/11/12
to
On 2012-12-11, MG <marc...@SPAMxs4all.nl> wrote:
The implied question was how good is your Swedish compared to his
English ? :-)
> On 11-dec-2012 4:11, Arne Vajhøj wrote:
>> How good is your Swedish?
>
> Why, did I recently misspell something in Swedish whilst,
> repeatedly, calling someone 'dumb'?
>
Jan-Erik comes from Sweden.
>> How good is your Swedish?
>
> Why, did I recently misspell something in Swedish whilst,
> repeatedly, calling someone 'dumb'?
>
The implied question was how good is your Swedish compared to his
English ? :-)
MG
Dec 11, 2012, 7:42:13 AM12/11/12
to
On 11-dec-2012 12:47, johnso...@gmail.com wrote:
> The VCI API documentation can be found here.
>
> http://starlet.deltatel.ru/vci1.html
Thanks! I'll save that to PDF, for safe keeping.
> The VCI API documentation can be found here.
>
> http://starlet.deltatel.ru/vci1.html
> The Digital employee that wrote that documentation clearly cared
> about the API. That manual was a labor of love. It's quite
> detailed and incredibly accurate. Not bad for something that was
> written nearly 20 years ago! I owe that an employee some beer.
> I could never have written what I did without that documentation.
guess it got better with age, not to mention DEC's standards and
habits as far as documentation in general go (and compared to
what contemporaries provide nowadays).
> In this case, the application was going to exchange only one
> UDP packet in a request/response fashion. While there would
> be more than one instance of the application at a time, each one
> would have a monogamous relationship with its Linux based buddy.
> And the linux based process was going to be in the driver's seat
> with the VMS host process acting as responsive slave. So one
> process to one process. One request. One reply.
> I think part of my issue was caused by working with a 10 GigE card in a
> PCI-X slot. So copying large amounts of data on and off that card was
> relatively expensive. Placing the card in a PCI Express v2 slot would
> have been a better choice, but that wasn't a possibility for me at
> the time.
NICs themselves are quite expensive (especially the PCI-E ones).
Interesting that you also tried 10 GbE. Did you set up a host-to-host
configuration, or did you also have a switch at your disposal?
> I felt that the C code to compute the IP header checksum was slower
> than I expected. Macro-32 might do better in this area.
Intel Itanium Assembler (IAS) for VMS?
> You can find some example VCI code in an old VMS freeware CD.
> I think it was v5 or v6 that had a working pcapvcm.c/vci_jacket.mar
> for the tcpdump utility. That one came in two flavors. One that
> used SYS$QIO and the other did VCI. I believe they have a few bugs
> in their VCI usage which caused crashes and that code was ultimately
> pulled. If you are good with the great google, you can find it.
pointing me to it.
> Hope that helps a bit.
- MG
MG
Dec 11, 2012, 7:51:19 AM12/11/12
to
On 11-dec-2012 13:41, Simon Clubley wrote:
> Jan-Erik comes from Sweden.
>
> The implied question was how good is your Swedish compared to his
> English ? :-)
How good is his Dutch, I as a fellow non-anglophone then asked.
> Jan-Erik comes from Sweden.
>
> The implied question was how good is your Swedish compared to his
> English ? :-)
Since he was so gratuitously hurling adjectives at me.
- MG
Joseph Huber
Dec 11, 2012, 8:50:20 AM12/11/12
to
With VMS 7.3,TCPIP 5.4 on a 600MHz XP1000, DE500 100Mbit Ethernet
I get 7.5 MByte/sec with FTP.
With all the FTP and TCP protocol overhead it seems to be the maximum
transfer rate one can get. (On some Linux systems I see the same 75%
of raw Ethernet capacity).
--
Remove NOREPLY. from Email address.
Joseph Huber, http://www.huber-joseph.de
MG
Dec 11, 2012, 9:16:28 AM12/11/12
to
On 11-dec-2012 14:50, Joseph Huber wrote:
> It seems on older hardware/VMS/TCPIP stack it was much better:
>
> With VMS 7.3,TCPIP 5.4 on a 600MHz XP1000, DE500 100Mbit Ethernet
> I get 7.5 MByte/sec with FTP.
> With all the FTP and TCP protocol overhead it seems to be the maximum
> transfer rate one can get. (On some Linux systems I see the same 75%
> of raw Ethernet capacity).
Interesting. Now that you mention it, that may also explain why
> It seems on older hardware/VMS/TCPIP stack it was much better:
>
> With VMS 7.3,TCPIP 5.4 on a 600MHz XP1000, DE500 100Mbit Ethernet
> I get 7.5 MByte/sec with FTP.
> With all the FTP and TCP protocol overhead it seems to be the maximum
> transfer rate one can get. (On some Linux systems I see the same 75%
> of raw Ethernet capacity).
my experience with TCP/IP on my Multia/UDB hasn't been nearly as
painful (also running VMS V7.3, don't remember the exact version
of TCP/IP though). And that's mere 10BASE-TX.
- MG
Simon Clubley
Dec 11, 2012, 9:21:36 AM12/11/12
to
On 2012-12-11, MG <marc...@SPAMxs4all.nl> wrote:
that out in the past.
Personally, I try not to pull people up on their language, _especially_
when I know they are a non-native speaker. I was just interpreting the
question for you in case you didn't pick up on the implied question.
Simon.
PS: And for the record, both my Swedish and Dutch language skills are
non-existant :-) (although, as a complete aside, I still like to watch
foreign language films in their native language when possible).
Bob Koehler
Dec 11, 2012, 9:43:25 AM12/11/12
to
In article <ka6orf$fga$1...@solani.org>, Michael Kraemer <M.Kr...@gsi.de> writes:
>
> So the gist of all that is:
> it's the spin lock, stupid?
> The question arises: why does VMS use such
> an inefficient mechanism, whereas the
> Unixoids don't? Wouldn't it be better
> to use one of those indivisable instructions
> (compare-and-swap, test-and-set) instead?
No. Support for those indivisable instructions slows down the memory
>
> So the gist of all that is:
> it's the spin lock, stupid?
> The question arises: why does VMS use such
> an inefficient mechanism, whereas the
> Unixoids don't? Wouldn't it be better
> to use one of those indivisable instructions
> (compare-and-swap, test-and-set) instead?
subsystem so much that the CPU then has to crawl along with it.
UNIX uses what the underlying architecture has. UNIX on Alpha uses
the same locking instructions as VMS on Alpha. UNIX and VMS on VAXen
use indivisible instructions.
Spin locks have been around about as long as UNIX.
Bob Koehler
Dec 11, 2012, 9:45:21 AM12/11/12
to
In article <ka7dms$1001$1...@gwdu112.gwdg.de>, Joseph Huber <joseph...@NOREPLY.web.de> writes:
>
> It seems on older hardware/VMS/TCPIP stack it was much better:
>
> With VMS 7.3,TCPIP 5.4 on a 600MHz XP1000, DE500 100Mbit Ethernet
> I get 7.5 MByte/sec with FTP.
> With all the FTP and TCP protocol overhead it seems to be the maximum
> transfer rate one can get. (On some Linux systems I see the same 75%
> of raw Ethernet capacity).
One can always test drive a better stack to see if it's faster than
>
> It seems on older hardware/VMS/TCPIP stack it was much better:
>
> With VMS 7.3,TCPIP 5.4 on a 600MHz XP1000, DE500 100Mbit Ethernet
> I get 7.5 MByte/sec with FTP.
> With all the FTP and TCP protocol overhead it seems to be the maximum
> transfer rate one can get. (On some Linux systems I see the same 75%
> of raw Ethernet capacity).
UCX.
But this reminds me of how PDP-11 seemed to do DECnet faster than
VAXen.
Stephen Hoffman
Dec 11, 2012, 9:54:42 AM12/11/12
to
(architecture-specific) locking primitives you mentioned.
The "fun" here is usually with the contention; when the spinlock
protects too much of the shared activities, which means its lit for far
too much of the time, and accessors are waiting. This is where
splitting up data structures and spinlocks is a (potential) solution;
increasing the amount of work that can occur in parallel.
The usual approach when investigating these cases is PC tracing and
spinlock tracing, and particularly figuring out where the code is
spending its time under load. That might be waiting for some spinlock,
or with buffer-copy routines or who-knows-what. I'd also look for
alignment faults, as even a few of those can be detrimental to
performance-critical code. Some of the high-level
instruction-scheduling wrinkles are mentioned here:
<http://labs.hoffmanlabs.com/node/160>. (AFAIK, various of the
performance-related tools were never ported to OpenVMS.)
Using VCI avoids the not-inconsequential overhead of the change-mode,
which is useful for performance reasons. VCI is most commonly used for
driver-related work and driver-to-driver communications, where
"ordinary" application code operating in user-mode might more readily
use $qio or $io_perform to reach the Ethernet. The latter system
service is somewhat lighter-weight, too.
--
Pure Personal Opinion | HoffmanLabs LLC
johnso...@gmail.com
Dec 11, 2012, 7:14:21 PM12/11/12
to
> This is where splitting up data structures and
> spinlocks is a (potential) solution; increasing
> the amount of work that can occur in parallel.
VMS rides on the shoulders of a handful of
spinlocks. MMG, SCHED, and IOLOCK8
come to mind. Linux used to have a single
kernel spinlock. But the community smashed
that apart years ago. I think that's why you see
Linux and x86 boxes readily tackling larger
boxes. See the Intel Phi coprocessor as an
example.
But even separate from judicious use of
spinlocks, I really thought that calling things
like sch_std$wake (I no longer have the code
so going by memory) took a long time. On
an rx8640, it was something like 7-10 micros
on a relatively unloaded box. That's separate
from getting the SCHED spinlock! Yikes!
At that point the scheduler should draw a hot
bubble bath and a glass of wine.
Perhaps Tukwila based boxes fare better. To me,
that kind of operation of poke the scheduler
to make this process compute ready should
be a microsecond at most. From what I was
told, the alpha did better in this type of operation.
But I don't have access to any VMS anymore so
I can't say one way or another.
Times have changed obviously. And the people
who knew the kernel at HP aren't there anymore
so these things can't be fixed.
> I'd also look for alignment faults
the help of the module in SDA, I think I purged
the ones that I had control over.
EJ
glen herrmannsfeldt
Dec 11, 2012, 8:05:03 PM12/11/12
to
johnso...@gmail.com wrote:
>> This is where splitting up data structures and
>> spinlocks is a (potential) solution; increasing
>> the amount of work that can occur in parallel.
> I certainly agree with that. Too much inside of
> VMS rides on the shoulders of a handful of
> spinlocks. MMG, SCHED, and IOLOCK8
> come to mind. Linux used to have a single
> kernel spinlock. But the community smashed
> that apart years ago. I think that's why you see
> Linux and x86 boxes readily tackling larger
> boxes. See the Intel Phi coprocessor as an
> example.
I suppose I believe that a uniprocessor system should be
>> This is where splitting up data structures and
>> spinlocks is a (potential) solution; increasing
>> the amount of work that can occur in parallel.
> I certainly agree with that. Too much inside of
> VMS rides on the shoulders of a handful of
> spinlocks. MMG, SCHED, and IOLOCK8
> come to mind. Linux used to have a single
> kernel spinlock. But the community smashed
> that apart years ago. I think that's why you see
> Linux and x86 boxes readily tackling larger
> boxes. See the Intel Phi coprocessor as an
> example.
able to run without spinlocks, assuming a reasonably interrupt
system.
But when you get to multiprocessor systems, and unless they have
special hardware to help synchronize what the different processors
are doing (rare), then spinlocks are it.
-- glen
Paul Sture
Dec 12, 2012, 4:28:38 AM12/12/12
to
In article <5tZHFt...@eisner.encompasserve.org>,
It was quite a few years before I saw the same snappy responses out of a
VMS box that I had got used to with PDP-11s, but of course VMS was doing
a lot of extra work in the background and could support a lot more users
simultaneously.
VMS box that I had got used to with PDP-11s, but of course VMS was doing
a lot of extra work in the background and could support a lot more users
simultaneously.
Paul Sture
Dec 12, 2012, 5:01:54 AM12/12/12
to
In article <50c63473$0$3478$e4fe...@dreader37.news.xs4all.nl>,
came into being.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
You haven't experienced fully paid for support, have you? Typically a
humble developer in a large organisation will not be able to go direct
to HP (or Compaq or DEC before HP), but have to go through a designated
contact.
Past subjects discussed in this group would have elicited a "Can we sell
you consultancy?" offer from DEC/Compaq/HP support.
And anyway, isn't it normal for folks who have a common interest to want
to get together to discuss it?
> Again, I wasn't asking, requesting or remotely insinuating a need for
> help or assistance, whatsoever. I already pointed this out, several
> times. If you think I were, please cite me the parts where I was
> allegedly 'asking'/'requesting'/etc. for 'assistance' or 'help'.
Well you were the one who wanted to know why TCP/IP Services seem to be
slow. This group is full of enquiring minds who would like to find out
why, hence the questions about version numbers.
> It's also polite to not lecture someone constantly.
Pot calling kettle.
MG <marc...@SPAMxs4all.nl> wrote:
> On 10-dec-2012 19:49, David Froble wrote:
> > Someone might infer from a poorly asked question that you're have some
> > difficulty on a production related issue, and devote significant time to
> > attempt to help you with a real problem. It's not very nice to cause
> > them to devote valuable time to something when it's just a matter of
> > curiosity.
>
> On 10-dec-2012 19:49, David Froble wrote:
> > Someone might infer from a poorly asked question that you're have some
> > difficulty on a production related issue, and devote significant time to
> > attempt to help you with a real problem. It's not very nice to cause
> > them to devote valuable time to something when it's just a matter of
> > curiosity.
>
> People with commercial interests shouldn't be here in the first place.
Nonsense. This news group started long before the Hobbyist programme
came into being.
> Actually, that's quite lamentable if you ask me. (Aren't commercial
> users paying HP good money for their so-called support?!) A bit of a
> cheapskate mentality, to then use the Usenet as an 'helpdesk'.
humble developer in a large organisation will not be able to go direct
to HP (or Compaq or DEC before HP), but have to go through a designated
contact.
Past subjects discussed in this group would have elicited a "Can we sell
you consultancy?" offer from DEC/Compaq/HP support.
And anyway, isn't it normal for folks who have a common interest to want
to get together to discuss it?
> Again, I wasn't asking, requesting or remotely insinuating a need for
> help or assistance, whatsoever. I already pointed this out, several
> times. If you think I were, please cite me the parts where I was
> allegedly 'asking'/'requesting'/etc. for 'assistance' or 'help'.
slow. This group is full of enquiring minds who would like to find out
why, hence the questions about version numbers.
> It's also polite to not lecture someone constantly.
Paul Sture
Dec 12, 2012, 5:09:01 AM12/12/12
to
In article <50c683df$0$3099$e4fe...@dreader34.news.xs4all.nl>,
MG <marc...@SPAMxs4all.nl> wrote:
> On 10-dec-2012 22:01, Simon Clubley wrote:
> > To MG:
> >
> > Usenet has been around for 30 years now and I've been using it for the
> > last 20 years. One of the common factors over all that time has been
> > the ability of people of shared interests to talk to one another, share
> > ideas/experiences and be exposed to concepts they may never have realised
> > on their own.
>
> Guess what I tried to do? However, did you see the first few replies?
> I wouldn't dare to describe them as sociopathic, but some just might.
>
>
> > People of all experiences and skill levels interact together across
> > these newsgroups without regard for whether someone is or is not a
> > "commercial" or professional person in that area of interest and
> > everyone is better off as a result.
>
> Some people seem to be more interested in version numbers and end up
> being so intensely focused on it that they occasionally tend to
> forget what some threads are about.
The point about version numbers is that they are very valuable
information when it comes to assessing a problem.
Specifying software versions is absolutely industry standard when
submitting any software performance report. Why should here be any
different just because a support contract isn't in place?
MG <marc...@SPAMxs4all.nl> wrote:
> On 10-dec-2012 22:01, Simon Clubley wrote:
> > To MG:
> >
> > Usenet has been around for 30 years now and I've been using it for the
> > last 20 years. One of the common factors over all that time has been
> > the ability of people of shared interests to talk to one another, share
> > ideas/experiences and be exposed to concepts they may never have realised
> > on their own.
>
> Guess what I tried to do? However, did you see the first few replies?
> I wouldn't dare to describe them as sociopathic, but some just might.
>
>
> > People of all experiences and skill levels interact together across
> > these newsgroups without regard for whether someone is or is not a
> > "commercial" or professional person in that area of interest and
> > everyone is better off as a result.
>
> Some people seem to be more interested in version numbers and end up
> being so intensely focused on it that they occasionally tend to
> forget what some threads are about.
The point about version numbers is that they are very valuable
information when it comes to assessing a problem.
Specifying software versions is absolutely industry standard when
submitting any software performance report. Why should here be any
different just because a support contract isn't in place?
johnso...@gmail.com
Dec 12, 2012, 7:29:24 AM12/12/12
to
> That's certainly also my experience, not to
> mention that the 10 GbE NICs themselves are
> quite expensive (especially the PCI-E ones).
The price difference between 10 GbE in a
> mention that the 10 GbE NICs themselves are
> quite expensive (especially the PCI-E ones).
Linux box and VMS box is awful. You would
pay less than 500 USD but if it's for VMS,
its 5000 USD. At least it was. To be fair, it
is built to the modern tukwilla boxes.
> Interesting that you also tried 10 GbE. Did you
> set up a host-to-host configuration, or did you
> also have a switch at your disposal?
in the network switch propaganda, it would
only add a few microseconds. Some very fancy
ones will do it in less.
>> Macro-32 might do better in this area.
> Speaking of which, have you ever tried
> anything with the 'official' Intel Itanium
> Assembler (IAS) for VMS?
had to be discontinued so I didn't get the chance.
The paucity of documentation wasn't reassuring.
Before I forget, I will mention one more thing.
If anyone does venture into the VCI rabbit hole,
which is terrific fun, you might get utility out of
setting the debug flags in the LSB for your
NIC. The drivers kick out decent trace data
which can then be seen in SDA. Something
like LAN trace show all or akin to that. There
won't be much there until you set those flags.
I felt I had good evidence for some time lost
between the driver receiving the frame (lower
VCM) and it handed over to the upper VCM
(the callbacks you give to VCI) I could never
quite figure out who squandered a good 10
microseconds at times.
There are some interrupt coalescing flags
you can set to adjust some of that behavior.
But I couldn't seem to influence the results.
I really just wanted the driver the frame ASAP.
But it seemed to always want to protect me.
Of course the drivers vary a bit based on the
exact box type so maybe the more recent ones
are better in this regard. I believe there is a file
buried in sys$help:lan_???? that details some
of them. The listing files for the drivers also
provide clues about options that might work.
EJ
Rod Regier
Dec 12, 2012, 7:39:31 AM12/12/12
to
On Sunday, December 9, 2012 1:49:47 PM UTC-4, MG wrote:
> Has anyone gotten these to function at acceptable speeds? (Yes, I have jumbo frames and such enabled.) I gave up, well, as far as HP TCP/IP Services NFS, FTP, SFTP, etc. go. MultiNet seems fine, but I don't think it's worth the hassle to mess around with additional PAKs, neither did I like the configuration interface much.
[snip]
FWIW, I have acheived say 85% utilization of a gigabit LAN connection between an OpenVMS server and a netbook running W7 performing a non-trivial FTP "put" transfer. That was without any special tuning of OpenVMS or the TCPIP Services for OpenVMS IP stack. I have also seen horrible LAN transfer speeds when the OpenVMS node network port and the associated switch disagreed about duplex mode.
LANCP is a great tool for confirming such issues if you suspect same.
> Has anyone gotten these to function at acceptable speeds? (Yes, I have jumbo frames and such enabled.) I gave up, well, as far as HP TCP/IP Services NFS, FTP, SFTP, etc. go. MultiNet seems fine, but I don't think it's worth the hassle to mess around with additional PAKs, neither did I like the configuration interface much.
[snip]
FWIW, I have acheived say 85% utilization of a gigabit LAN connection between an OpenVMS server and a netbook running W7 performing a non-trivial FTP "put" transfer. That was without any special tuning of OpenVMS or the TCPIP Services for OpenVMS IP stack. I have also seen horrible LAN transfer speeds when the OpenVMS node network port and the associated switch disagreed about duplex mode.
LANCP is a great tool for confirming such issues if you suspect same.
MG
Dec 12, 2012, 7:48:27 AM12/12/12
to
On 12-dec-2012 11:09, Paul Sture wrote:
> The point about version numbers is that they are very valuable
> information when it comes to assessing a problem.
/Again/, I'm not having a 'problem'.
> The point about version numbers is that they are very valuable
> information when it comes to assessing a problem.
- MG
MG
Dec 12, 2012, 8:01:37 AM12/12/12
to
On 12-dec-2012 11:01, Paul Sture wrote:
> Nonsense. This news group started long before the Hobbyist programme
> came into being.
Did you see what preceded my remark? If you can't be bothered to read
> Nonsense. This news group started long before the Hobbyist programme
> came into being.
into something, to see its context, then you shouldn't bother at all.
A bit of a waste of time.
> You haven't experienced fully paid for support, have you?
job opportunities and none of the 'old boys' will allow someone of
my age to get in either. Well, besides that, there doesn't appear
to be much interest for people with VMS skills to begin with and
HP has once again shown no interest to go anywhere with VMS. (The
transcript of that HP Discover 2012 presentation that Hoffman kindly
composed recently showed that once more.)
> Well you were the one who wanted to know why TCP/IP Services seem
> to be slow. This group is full of enquiring minds who would like
> to find out why, hence the questions about version numbers.
am finally done bothering with. You know, some people did get the
purpose of this thread and made interesting contributions. Like
Eric Johnson, whose contributions were very interesting. Did you
even see those?
>> It's also polite to not lecture someone constantly.
>
> Pot calling kettle.
I'm not the type to lecture someone or to go off preaching.
- MG
MG
Dec 12, 2012, 8:11:56 AM12/12/12
to
On 12-dec-2012 13:39, Rod Regier wrote:
> FWIW, I have acheived say 85% utilization of a gigabit LAN
> connectionbetween an OpenVMS server and a netbook running
> FWIW, I have acheived say 85% utilization of a gigabit LAN
> W7 performing a non-trivial FTP "put" transfer. That was
> without any special tuning of OpenVMS or the TCPIP Services
> for OpenVMS IP stack. I have also seen horrible LAN transfer
> speeds when the OpenVMS node network port and the associated
> switch disagreed about duplex mode. LANCP is a great tool for
> confirming such issues if you suspect same.
That does indeed seem like a common cause and I've indeed used
> without any special tuning of OpenVMS or the TCPIP Services
> for OpenVMS IP stack. I have also seen horrible LAN transfer
> speeds when the OpenVMS node network port and the associated
> switch disagreed about duplex mode. LANCP is a great tool for
> confirming such issues if you suspect same.
LANCP often, at first to manually set things like jumbo frames
and which I eventually set with the "LAN_FLAGS" parameter.
Such things did improve things slightly, but it's still way
too slow and it pains me to see Windows outperform VMS in
these areas...
- MG
Bob Koehler
Dec 12, 2012, 10:02:54 AM12/12/12
to
In article <ka8l7v$c0d$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> I suppose I believe that a uniprocessor system should be
> able to run without spinlocks, assuming a reasonably interrupt
> system.
IIRC, uniprocessor Alphas do exactly that.
> I suppose I believe that a uniprocessor system should be
> able to run without spinlocks, assuming a reasonably interrupt
> system.
Bob Koehler
Dec 12, 2012, 10:17:57 AM12/12/12
to
In article <a1efbe2a-414b-48ac...@googlegroups.com>, johnso...@gmail.com writes:
>
>> This is where splitting up data structures and
>> spinlocks is a (potential) solution; increasing
>> the amount of work that can occur in parallel.
>
> I certainly agree with that. Too much inside of
> VMS rides on the shoulders of a handful of
> spinlocks. MMG, SCHED, and IOLOCK8
> come to mind. Linux used to have a single
> kernel spinlock. But the community smashed
> that apart years ago.
So if they are not using spinlocks, how do Linux multi-processor
>
>> This is where splitting up data structures and
>> spinlocks is a (potential) solution; increasing
>> the amount of work that can occur in parallel.
>
> I certainly agree with that. Too much inside of
> VMS rides on the shoulders of a handful of
> spinlocks. MMG, SCHED, and IOLOCK8
> come to mind. Linux used to have a single
> kernel spinlock. But the community smashed
> that apart years ago.
systems syncronize between CPUs? Do x86 processors really do a
multi-cpu atomic synchronization on exchange instructions? How
about Linux on other CPU architectures?
0 new messages