Printable View
For a project I'm doing, I need to access the jiffies counter (it's a raw ethernet/ip/tcp utility that needs timestamp support). Unfortunately, I can't find out how to access the jiffies variable from user space.
I can't find a syscall, a header file that would define it, or anything usable on Google. Is there a way to directly access the value, perhaps by opening /dev/mem and extracting it?
There is no user space access that I know of. You could build your own kernel with support for it though: Kernel command using Linux system calls
If you all you need is a timestamp, why not just use clock_gettime(CLOCK_REALTIME)?
gg
There might be something under /proc that gives the current jiffies. Away from a Linux system at the moment so I can't check.
Quote:
Originally Posted by memcpy
/proc/uptime will give you the uptime in hundredths of a second.Quote:
Originally Posted by brewbuck
If you really want the jiffies, you don't have to compile a special kernel; "jiffies_64" is a kernel space global, so a simple kernel module could map it to a char /dev file.
But that seems a little zany. Ala. Codeplug, why don't you just use gettimeofday(), which reports in microseconds?
High-Resolution Calendar - The GNU C Library
>> why don't you just use gettimeofday()
Check out this man page for gettimeofday(), specifically the "CONFORMING TO" section: gettimeofday(2) - Linux manual page
gg
Thanks, (miliseconds is accurate enough) now I've gotta find the functions that convert from uptime -> jiffies, and jiffies -> msec.Quote:
Originally Posted by MK27
I know to google.. :LQuote:
Originally Posted by Codeplug
(ot) I've tried every variation of using gettimeofday()'s output, and none match standard timestamps I've seen on *real* packets. The htonl()/htons() functions don't seem to be any closer to what I want. Also, correct me if I'm wrong, but I saw on the Linux kernel source that tcp timestamps were formed by manipulating the jiffies.
Codeplug's point was that gettimeofday is depreciated in favour of clock_gettime, which I didn't know.
Could be -- I haven't done much with tcp packets directly. If so, that may be an issue -- altho the system clock is most likely jiffie based too, the clock functions might use the hardware clock, which isn't. But I'm dubious. I'm also confused by your reference to the big endian functions -- beyond simple conversion, what does htonl() have to do with this?Quote:
Originally Posted by memcpy
Your best bet is to post some code and explain in detail what you were hoping for vs. what happened.
The kernel does calculate jiffies per second at start-up, but I don't think that is exported to userspace. Another issue is that the userspace latency is 10ms -- ie, you cannot get any finer granularity than that with accuracy (I think there are some options in the 3.0 kernel to do with this). So maybe you do need a kernel module; the hardest part of that is just learning the methodology. If you google for the "hello world" kernel module, all you need on top of that is a char driver to create a /dev file for the interface. The 2nd or 3rd edition of "linux device drivers" is free online and explains how to do this.Quote:
Thanks, (miliseconds is accurate enough) now I've gotta find the functions that convert from uptime -> jiffies, and jiffies -> msec.
Also, a good place to ask questions like this is the kernel mailing list. Just beware after you sign up that there are hundreds of posts a day.
>> now I've gotta find the functions that convert from uptime -> jiffies, and jiffies -> msec.
Why are your trying to convert to/from jiffies? You say you have a "utility that needs timestamp support", but what does that mean? What exactly are your trying to do?
>> I know to google..
That's a good skill to have. I was replying to MK27 as to why one may call clock_gettime(CLOCK_REALTIME) instead of gettimeofday().
>> ... and none match standard timestamps I've seen on *real* packets.
>> ... it's a raw ethernet/ip/tcp utility ...
Ah, we're getting closer to what it is you are really trying to achieve.
gg
Quote:
Originally Posted by MK27
Alright, here's my code so far:
Code:
Code:char *build_tcp_timestamp(uint32_t tsval, uint32_t tsecr)
{
struct tcp_timestamp time;
char *ret = malloc(s_tme + 1);
memset(&time, TCPOPT_NOP, s_tme);
if (!tsval) {
struct timeval now;
gettimeofday(&now, NULL);
time.tsval = htonl((uint32_t) now.tv_sec);
}
time.tsecr = htonl(tsecr);
time.kind = TCPOPT_TIMESTAMP;
time.length = TCPOLEN_TIMESTAMP;
memcpy(ret, &time, s_tme);
return ret;
}
Where it's called:
Code:struct iovec *build_raw(struct pkt_info_t *syn)
As you would probably expect, it works / compiles fine (no segfaults), but the number is grossly incorrect when calculating "tsval". I'm using a PF_PACKET socket to write/read, and comparing the timestamps, they're always different. I'm guessing the disparity is how I'm getting the system time..Code:{
if (syn->p_flags & TH_SYN) {
syn->opts = build_syn_ops();
syn->opt_len = 24;
} else if (syn->p_flags & TH_ACK) {
syn->opts = build_ack_ops(syn->p_tsval, syn->p_tsecr);
syn->opt_len = 12;
}
struct iovec *pio = malloc(s_iov);
pio->iov_len = s_eth + s_iph + s_tcp + syn->opt_len + syn->data_len;
pio->iov_base = calloc(1, pio->iov_len);
build_eth_hdr(pio, syn->p_src_mac, syn->p_dst_mac);
build_ip_hdr(pio, (uint32_t) pio->iov_len, syn->p_src_ip,
syn->p_dst_ip);
build_tcp_hdr(pio, syn->p_src_port, syn->p_dst_port,
syn->p_seq, syn->p_ack, syn->opt_len,
syn->p_flags, syn->opts, syn->data,
syn->opt_len, syn->data_len);
memcpy((char *)pio->iov_base + s_eth + s_iph + s_tcp,
syn->opts, syn->opt_len);
memcpy((char *)pio->iov_base + s_eth + s_iph + s_tcp + syn->opt_len,
syn->data, syn->data_len);
return pio;
}
@everyone who said to use kernel modules: I'm not sure about the portability of kernel modules: I'm writing it for distribution on linux and mac OS. For mac, I'm using a BPF socket instead of a packet socket, but other than that, the programs are relatively similar.
If I was going to get the jiffies, I would #ifdef __linux__ and put in jiffies, and otherwise, use clock_gettimeof..whatever.
Transmission Control Protocol - Wikipedia, the free encyclopedia
RFC 1323 - TCP Extensions for High PerformanceQuote:
TCP timestamps are not normally aligned to the system clock and start at some random value. Many operating systems will increment the timestamp for every elapsed milisecond; however the RFC only states that the tics should be proportional.
Without knowing what your tool is trying to achieve, it seems to me that you need a [real] timestamp of the previous packet so that a time difference can be calculated. Once you know the difference, you can calculate the proportional amount of tics to add to TSval.Quote:
The timestamp value to be sent in TSval is to be obtained from a (virtual) clock that we call the "timestamp clock". Its values must be at least approximately proportional to real time, in order to measure actual RTT.
gg
Dude, thanks. I completely missed that ^.Quote:
Originally Posted by Codeplug
(ot) However, because I'm the one sending the *first* packet (syn), I need to initiate the timestamp on something.
According to wikipedia:
>> TCP timestamps are not normally aligned to the system clock and start at some random value.
1 seems like a good place to start.
gg
And course, if you're not comfortable with "1", you could just start with something based on the current clock time. I'm inferring here that the remote party will then send you packets stamped using it's own system, and that this does not have to match yours, it just has to be correct relative to itself. Hence, the tcp header has two timestamps -- one it is created with, and an echo of the last timestamp received by the other party when the packet was created. I doubt there is any need for them to match up on some absolute scale.
It seems to me the timestamps have two purposes:
1) To calculate round-trip time. You don't need an actual timestamp on the packet at all for that, you'd just need a unique identifier so you can track them. But using the timestamp saves keeping a separate record and simplifies the protocol.
2) To keep packets in correct order, in which case you just have to insure the timestamps are properly consecutive.