Like Tree3Likes
  • 1 Post By Codeplug
  • 1 Post By Codeplug
  • 1 Post By Codeplug

Jiffies

This is a discussion on Jiffies within the Linux Programming forums, part of the Platform Specific Boards category; For a project I'm doing, I need to access the jiffies counter (it's a raw ethernet/ip/tcp utility that needs timestamp ...

  1. #1
    Registered User
    Join Date
    Dec 2011
    Posts
    795

    Jiffies

    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?

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    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

  3. #3
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    There might be something under /proc that gives the current jiffies. Away from a Linux system at the moment so I can't check.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by memcpy View Post
    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).
    Quote Originally Posted by brewbuck View Post
    There might be something under /proc that gives the current jiffies.
    /proc/uptime will give you the uptime in hundredths of a second.

    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
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    >> 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

  6. #6
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    Quote Originally Posted by MK27 View Post
    /proc/uptime will give you the uptime in hundredths of a second.

    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
    Thanks, (miliseconds is accurate enough) now I've gotta find the functions that convert from uptime -> jiffies, and jiffies -> msec.

    Quote Originally Posted by Codeplug View Post
    >> 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
    I know to google.. :L

    (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.


  7. #7
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Codeplug's point was that gettimeofday is depreciated in favour of clock_gettime, which I didn't know.

    Quote Originally Posted by memcpy
    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.
    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?

    Your best bet is to post some code and explain in detail what you were hoping for vs. what happened.

    Thanks, (miliseconds is accurate enough) now I've gotta find the functions that convert from uptime -> jiffies, and jiffies -> msec.
    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.

    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.
    Last edited by MK27; 12-14-2011 at 04:28 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    >> 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

  9. #9
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    Quote Originally Posted by MK27 View Post
    Your best bet is to post some code and explain in detail what you were hoping for vs. what happened.

    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)
    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;
    }
    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..

    @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.




    Last edited by memcpy; 12-14-2011 at 05:53 PM.

  10. #10
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    Transmission Control Protocol - Wikipedia, the free encyclopedia
    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.
    RFC 1323 - TCP Extensions for High Performance
    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.
    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.

    gg

  11. #11
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    Quote Originally Posted by Codeplug View Post
    Transmission Control Protocol - Wikipedia, the free encyclopedia


    RFC 1323 - TCP Extensions for High Performance


    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.

    gg
    Dude, thanks. I completely missed that ^.

    (ot) However, because I'm the one sending the *first* packet (syn), I need to initiate the timestamp on something.

  12. #12
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    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

  13. #13
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    Last edited by MK27; 12-15-2011 at 05:23 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Get jiffies?
    By pgzh in forum Linux Programming
    Replies: 6
    Last Post: 03-17-2008, 10:30 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21