It has been quite a while since my original question was sent, but I
finally have enough information to make sending a summary
worthwhile. The bottom line is that all information points to a poorly
written driver. I obtained a more recent version of the driver and
found that trivial operations now proceed normally while data is
moving over the parallel port, but non-trivial actions are still
severely delayed. I also discovered that all of our workstations have
internal parallel ports (I wish our Sun Sales person had told us
that). I am in the process of obtaining the special cable required to
use that port so I can test using it rather than the Artecon parallel
port to drive a printer. I have been led to believe the Sun driver is
properly written and does not unduly impact the other software
executing on the workstation.
As to my POOR analysis of the vmstat output... it turns out that the
machine on which the test was performed can sustain triple the
interrupt and context switch rates when performing other operations,
such as a network disk to local disk tree copy.
People reported that with other parallel port solutions (i.e. not
using the Artecon port) they achieved vastly better data transfer
rates than I have seen with either version of the Artecon driver.
Finally, people identified other add-on parallel port solutions from
specific vendors. I will probably be investigating them if the
internal parallel port does not meet our needs.
My thanks to:
erp@microplex.com (Edward R. Powell)
lisa@magma.COM (Lisa Barnes)
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
martin@gea.hsr.it (Martin Achilli)
mshon@sunrock.East.Sun.COM (Michael J. Shon {*Prof Services} Sun Rochester)
David Fan <david@magma.COM>
Marc S. Gibian
Telos Consulting Services phone: (617) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
----------- original question -------------
I have been evaluating printers for my customer's product. As part of
that work, I have had to move to a parallel port connection between
the SPARCstation and the printer(s) being tested as serial connections
have no hope of moving data fast enough. This test is currently being
performed on a SPARCstation 10/30 using the ArtePort 300P Sbus card
providing the parallel port printing to a brother HL-660 printer with
its Postscript option installed. I printed a one page Postscript
graphics output produced with xwd, generating a 1.3 meg file in the
print queue. I noticed that the machine became so heavily loaded that
there was significant (1+ second) or greater delay tracking the mouse
(running X11R5/Motif 1.23 from OSF), and many second delay
auto-raising windows getting pointer focus or responding to keyboard
commands in my shell windows. I ran a vmstat with the following a
typical sample:
procs memory page disk faults cpu
r b w avm fre re at pi po fr de sr d0 d1 d2 d3 in sy cs us sy id
2 0 0 0 4364 0 0 0 0 0 0 0 0 0 0 0 361 51 225 82 18 0
3 0 0 0 4364 0 37 0 0 0 0 0 5 0 0 0 357 36 141 39 61 0
2 0 0 0 4364 0 11 0 0 0 0 0 0 0 0 0 342 47 193 57 43 0
3 0 0 0 4360 0 2 0 0 0 0 0 0 0 0 0 337 44 219 79 21 0
1 0 0 0 4356 0 0 0 0 0 0 0 0 0 0 0 336 46 225 81 19 0
2 0 0 0 4312 0 0 0 0 0 16 0 1 0 0 0 337 69 203 36 63 1
1 0 0 0 4328 0 0 0 0 0 0 0 0 0 0 0 339 63 219 81 19 0
5 0 0 0 4352 0 0 0 0 0 0 0 1 0 0 0 344 60 206 41 59 0
The parallel port is rated at 20K cps. A little math says that I am
getting held up by the interrupt rate of my SPARCstation 10/30.
1. Is the a correct analysis?
2. What order of magnitude change should I see if I keep everything
constant except that I replace the SPARCstation 10/30 with a 20?
3. Am I right in saying that I should expect this level of performance
unless I move to a parallel port based on more sophisticated
technology, such as Central Data's SCSI based parallel port hardware?
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:27 CDT