This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Sockets and Internet Protocols and the fly likes Measure the idle time of a client socket read Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "Measure the idle time of a client socket read" Watch "Measure the idle time of a client socket read" New topic
Author

Measure the idle time of a client socket read

Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

We know that reading a byte from a Java client socket is a blocking read, i.e. it will wait idle until the bytes are available in the socket. Is there any way to measure the idle time of the read?


SCJP, SCJD, SCWCD, SCBCD, SCEA
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

You can use System.currentTimeMillis(). In pseudo code:
To get the idle time between each byte you would need non-buffered (so no BufferedInputStream) single byte reads using the read() method.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

Rob Spoor wrote:You can use System.currentTimeMillis(). In pseudo code:
To get the idle time between each byte you would need non-buffered (so no BufferedInputStream) single byte reads using the read() method.


Hi, why non-buffered stream? What if I use the BufferedInputStream?
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

Rob Spoor wrote:You can use System.currentTimeMillis(). In pseudo code:
To get the idle time between each byte you would need non-buffered (so no BufferedInputStream) single byte reads using the read() method.


Plus I don't think the (end - start) is the idle time, but it also includes the time of the actual read.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18509
    
  40

Jiafan Zhou wrote:Plus I don't think the (end - start) is the idle time, but it also includes the time of the actual read.


True, but keep in mind that the actual operation should be relatively fast compared to the idle time.

If this is *not* the case, then this measurement would serve little purpose.... ie. what would be the purpose of knowing that you have 10ms of idle time for an operation that takes a second? If the network / operating system is keeping up, meaning no queuing up somewhere, there isn't really a problem.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

Jiafan Zhou wrote:
Rob Spoor wrote:You can use System.currentTimeMillis(). In pseudo code:
To get the idle time between each byte you would need non-buffered (so no BufferedInputStream) single byte reads using the read() method.


Hi, why non-buffered stream? What if I use the BufferedInputStream?

When you use a buffered stream (BufferedInputStream) you will not only be reading from the socket, but also from memory. When you perform a read operation the BufferedInputStream will try to fill its buffer before returning. If you request less than the buffer can hold you may end up waiting longer than you intend to.
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

Henry Wong wrote:
Jiafan Zhou wrote:Plus I don't think the (end - start) is the idle time, but it also includes the time of the actual read.


True, but keep in mind that the actual operation should be relatively fast compared to the idle time.

If this is *not* the case, then this measurement would serve little purpose.... ie. what would be the purpose of knowing that you have 10ms of idle time for an operation that takes a second? If the network / operating system is keeping up, meaning no queuing up somewhere, there isn't really a problem.


I don't totally agree with this. Usually the network read from the socket could be slow itself if reading from a large byte streams. I want to know what percentage of the idle item is occupied in the total read.

And since I don't know how long is the idle time, the idle time could be long as well. I want to know how long is the idle time and want to find out what and where generates this idle time.



Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Jiafan Zhou wrote:Plus I don't think the (end - start) is the idle time, but it also includes the time of the actual read.


That's true, but note that you are timing the whole operation to the nearest millisecond at best, whereas the time required to get a byte from the operating system's TCP/IP code would be measured in nanoseconds. There's a scale difference of about a million there.

And besides, the operating system does its own buffering, because TCP/IP works with packets. So this idea of recording the idle time per byte is kind of useless.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Jiafan Zhou wrote:I don't totally agree with this. Usually the network read from the socket could be slow itself if reading from a large byte streams. I want to know what percentage of the idle item is occupied in the total read.

And since I don't know how long is the idle time, the idle time could be long as well. I want to know how long is the idle time and want to find out what and where generates this idle time.


Why would the length of the stream being read affect the idle time in any way?

As for what generates the idle time, it's the operating system waiting for packets to come over a network connection. It doesn't look like you really understand the relative speeds of computers versus networks, so you ought to get out your pencil and do a bit of arithmetic. How fast is your computer? Let's suppose you have a 4GB machine -- that means it does 4 billion operations per second. And how fast is your network? Let's suppose you have a 10MB network -- that means it transmits 10 million bytes per second. Think about this for a while so you get some idea of what's important and what's trivial.
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

Paul Clapham wrote:
Jiafan Zhou wrote:I don't totally agree with this. Usually the network read from the socket could be slow itself if reading from a large byte streams. I want to know what percentage of the idle item is occupied in the total read.

And since I don't know how long is the idle time, the idle time could be long as well. I want to know how long is the idle time and want to find out what and where generates this idle time.


Why would the length of the stream being read affect the idle time in any way?

As for what generates the idle time, it's the operating system waiting for packets to come over a network connection. It doesn't look like you really understand the relative speeds of computers versus networks, so you ought to get out your pencil and do a bit of arithmetic. How fast is your computer? Let's suppose you have a 4GB machine -- that means it does 4 billion operations per second. And how fast is your network? Let's suppose you have a 10MB network -- that means it transmits 10 million bytes per second. Think about this for a while so you get some idea of what's important and what's trivial.


Thanks, Paul. The length of the stream should not affect the idle time. A long byte stream only makes the performance worse, plus the idle time.
Hold on, I am not particularly interested in the idle time that generated by the operating system. I am more interested in the idle time generated by the application. For example, if the server (sender of the packets) takes a nap while sending the packets, whereas the receiver uses the blocking read() to wait for receiving the packets, an idle time will be generated. This is what I am interested to know, in particular, the percentage of this idle time vs the actual read time.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

There is no way to know whether the delay between your code asking for bytes and your code receiving bytes is caused by the operating system waiting to receive bytes for your code, or by the operating system paging out your code, or by the operating system delaying your code because it's serving a higher-priority thread, or any number of other reasons I haven't thought of.

Also, what you said suggests that since reading from a socket is a blocking read, the application takes the opportunity to sneak out behind the printer and smoke a cigarette or something like that. No. It's blocking because it's waiting to get data from the operating system.
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

Paul Clapham wrote:There is no way to know whether the delay between your code asking for bytes and your code receiving bytes is caused by the operating system waiting to receive bytes for your code, or by the operating system paging out your code, or by the operating system delaying your code because it's serving a higher-priority thread, or any number of other reasons I haven't thought of.

Is there a way to know this wait (idle) time in a high level above the operating system such as JVM?
Surely when Java input stream (any kind, such as BufferedInputStream) reads from a Socket and the socket does not have any incoming messages, the waiting or idle time will be recorded by the thread?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Jiafan Zhou wrote:Is there a way to know this wait (idle) time in a high level above the operating system such as JVM?
Surely when Java input stream (any kind, such as BufferedInputStream) reads from a Socket and the socket does not have any incoming messages, the waiting or idle time will be recorded by the thread?


Why would the thread keep track of that? Like I said, there are dozens of reasons why a thread might be delayed. Anyway you can look at the public API for Thread and see for yourself that there aren't any such methods.

I have no idea why you have this obsession with idle time. You're trying to oversimplify things and then you're demanding that your computing environment should provide ways for you to measure your oversimplified ideas. What's really going on here?
Jiafan Zhou
Ranch Hand

Joined: Sep 28, 2005
Posts: 192

I am not a TCP/IP expert, but this is what I understand.

If a connection is established and one end socket does not have any incoming data, however, at the same time, we use the Java InputStream.read() API to read the data from the socket. SInce this read() is a blocking read, the current thread who execute this statement will be blocked until incoming data from the socket is available. This state is different from the one when there is data available to read from the Socket. As I have mentioned, what I am trying to do is very very simple, to measure the idle time when there is no data to read and the time when there is indeed data to read.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

You got that already in the first couple of posts to this thread. Everything after that was all about trivia.
 
Consider Paul's rocket mass heater.
 
subject: Measure the idle time of a client socket read
 
Similar Threads
socket programming : connect server to client
How to get CPU and Memory idle values using Java?
callableStatement.execute()
Non-blocking sockets
bandwidth measurement