Sponsored Content
Full Discussion: UNIX.com response times
Contact Us Post Here to Contact Site Administrators and Moderators UNIX.com response times Post 303003549 by Corona688 on Friday 15th of September 2017 02:48:18 PM
Old 09-15-2017
It's usually blazing fast for me, honestly. I've never seen anything but minute or two intervals of slow performance, then back to fast the majority of the time.
 

5 More Discussions You Might Find Interesting

1. Programming

Problem with implementing the times() function in C (struct tms times return zero/negative values)

Hello, i'm trying to implement the times() function and i'm programming in C. I'm using the "struct tms" structure which consists of the fields: The tms_utime structure member is the CPU time charged for the execution of user instructions of the calling process. The tms_stime structure... (1 Reply)
Discussion started by: g_p
1 Replies

2. Shell Programming and Scripting

feasibility of opening a website link from unix and get a response in the form of xml or html

i just wanted to know whether is it possible to open a website link and get a response in the form of xml or html format... the website is of local network... for example something like this wget http://blahblah.samplesite.com/blachblahcblach/User/jsp/ShowPerson.jsp?empid=123456 ... (2 Replies)
Discussion started by: vivek d r
2 Replies

3. Red Hat

Response Times

Hello all. Let me qualify my question by saying that I am struggling with how to ask the question I am semi green but have no issue reading up if pointed in the right direction. Please be gentle! A RHEL server 6.2. Hosts a statistical application that has some web apps and batch programming... (0 Replies)
Discussion started by: rsheikh01
0 Replies

4. What is on Your Mind?

Changing Times at UNIX.COM

Over the past year, I have written so much code at UNIX.COM, I've gained 4 KGs just sitting at my desk and not exercising! However, it seems that "no good deed goes unpunished" and not only have I sacrificed my health (gaining weight, not exercising as much), but there is also my family who is... (4 Replies)
Discussion started by: Neo
4 Replies

5. Shell Programming and Scripting

Choosing VPN server based on server response times

Hello all, I am using the VPN provider Private Internet Access. I am using the Raspberry Pi 4 with 4GB of RAM, performance on this upgraded board is great. Anyways I am connecting to its service using systemd's openvpn-client @ US_New_York_City.service I wonder if I can create a... (5 Replies)
Discussion started by: haloslayer255
5 Replies
tunelp(8)						     Linux Programmer's Manual							 tunelp(8)

NAME
tunelp - set various parameters for the lp device SYNOPSIS
tunelp <device> [-i <IRQ> | -t <TIME> | -c <CHARS> | -w <WAIT> | -a [on|off] | -o [on|off] | -C [on|off] | -r | -s | -q [on|off] | - T [on|off] ] DESCRIPTION
tunelp sets several parameters for the /dev/lp? devices, for better performance (or for any performance at all, if your printer won't work without it...) Without parameters, it tells whether the device is using interrupts, and if so, which one. With parameters, it sets the device characteristics accordingly. The parameters are as follows: -i <IRQ> specifies the IRQ to use for the parallel port in question. If this is set to something non-zero, -t and -c have no effect. If your port does not use interrupts, this option will make printing stop. The command tunelp -i 0 restores non-interrupt driven (polling) action, and your printer should work again. If your parallel port does support interrupts, interrupt-driven printing should be somewhat faster and efficient, and will probably be desirable. NOTE: This option will have no effect with kernel 2.1.131 or later since the irq is handled by the parport driver. You can change the parport irq for example via /proc/parport/*/irq. Read /usr/src/linux/Documentation/parport.txt for more details on parport. -t <TIME> is the amount of time in jiffies that the driver waits if the printer doesn't take a character for the number of tries dictated by the -c parameter. 10 is the default value. If you want fastest possible printing, and don't care about system load, you may set this to 0. If you don't care how fast your printer goes, or are printing text on a slow printer with a buffer, then 500 (5 seconds) should be fine, and will give you very low system load. This value generally should be lower for printing graphics than text, by a factor of approximately 10, for best performance. -c <CHARS> is the number of times to try to output a character to the printer before sleeping for -t <TIME>. It is the number of times around a loop that tries to send a character to the printer. 120 appears to be a good value for most printers in polling mode. 1000 is the default, because there are some printers that become jerky otherwise, but you must set this to `1' to handle the maximal CPU efficiency if you are using interrupts. If you have a very fast printer, a value of 10 might make more sense even if in polling mode. If you have a really old printer, you can increase this further. Setting -t <TIME> to 0 is equivalent to setting -c <CHARS> to infinity. -w <WAIT> is the number of usec we wait while playing with the strobe signal. While most printers appear to be able to deal with an extremely short strobe, some printers demand a longer one. Increasing this from the default 1 may make it possible to print with those print- ers. This may also make it possible to use longer cables. It's also possible to decrease this value to 0 if your printer is fast enough or your machine is slow enough. -a [on|off] This is whether to abort on printer error - the default is not to. If you are sitting at your computer, you probably want to be able to see an error and fix it, and have the printer go on printing. On the other hand, if you aren't, you might rather that your printer spooler find out that the printer isn't ready, quit trying, and send you mail about it. The choice is yours. -o [on|off] This option is much like -a. It makes any open() of this device check to see that the device is on-line and not reporting any out of paper or other errors. This is the correct setting for most versions of lpd. -C [on|off] This option adds extra ("careful") error checking. When this option is on, the printer driver will ensure that the printer is on- line and not reporting any out of paper or other errors before sending data. This is particularly useful for printers that normally appear to accept data when turned off. NOTE: This option is obsolete because it's the default in 2.1.131 kernel or later. -s This option returns the current printer status, both as a decimal number from 0..255, and as a list of active flags. When this option is specified, -q off, turning off the display of the current IRQ, is implied. -T [on|off] This option tell the lp driver to trust or not the IRQ. This option makes sense only if you are using interrupts. If you tell the lp driver to trust the irq, then, when the lp driver will get an irq, it will send the next pending character to the printer uncon- ditionally, even if the printer still claims to be BUSY. This is the only way to sleep on interrupt (and so the handle the irq printing efficiently) at least on Epson Stylus Color Printers. The lp driver automagically detects if you could get improved per- formance by setting this flag, and in such case it will warn you with a kernel message. NOTE: Trusting the irq is reported to corrupt the printing on some hardware, you must try to know if your printer will work or not... -r This option resets the port. It requires a Linux kernel version of 1.1.80 or later. -q [on|off] This option sets printing the display of the current IRQ setting. NOTES
-o, -C, and -s all require a Linux kernel version of 1.1.76 or later. -C requires a Linux version prior to 2.1.131. -T requires a Linux version of 2.1.131 or later. BUGS
By some unfortunate coincidence the ioctl LPSTRICT of 2.0.36 has the same number as the ioctl LPTRUSTIRQ introduced in 2.1.131. So, use of the -T option on a 2.0.36 kernel with an tunelp compiled under 2.1.131 or later may have unexpected effects. FILES
/dev/lp? /proc/parport/*/* tunelp 7 May 1999 tunelp(8)
All times are GMT -4. The time now is 10:28 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy