International Journal of Ethics in Engineering & Management Education TIME BASED EVENT MANAGEMENT WITH SNTP CLIENT AND SERVER

International Journal of Ethics in Engineering & Management Education Website: www.ijeee.in (ISSN: 2348-4748, Volume 1, Issue 1, January 2014)

38

TIME BASED EVENT MANAGEMENT WITH SNTP CLIENT AND SERVER

P. Aruna Sree Kumar.Keshamoni Assistant Professor, Dept of ECE Assistant Professor, Dept of ECE

RVR Institute of Engineering & Technology RVR Institute of Engineering & Technology Ibrahimpatan, Hyderabad, India Ibrahimpatan, Hyderabad, India [email protected] [email protected]

ABSTRACT: Every In-home Audio Video (A/V) appliance now-a-days is becoming multifunctional and the system that control these functions are also becoming larger. Time Synchronization with a standard time base is becoming one key requirement for these multi functional devices. In such a situation accurate time sharing system will be required to give precise time information to each device and give synchronize operation between different devices. This paper proposes a method of solving the challenge described above by implementing standard time based client running Simple Network Time Protocol (SNTP) application within an embedded home AV device and implementing SNTP server on PC (personal computer). First SNTP server in PC (personal computer) requests for a UTC (universal co-ordinate time) and obtains UTC from NTP (Network time protocol) server which is running in remote location through internet. Second the SNTP client in the AV (audio video) sub system requests for a precise time and obtains time information from the SNTP Server. Next the Real Time Clock (RTC) inside the AV system is adjusted with the SNTP client time with a call back mechanism. Time synchronization of the multiple events (like playing video file, playing audio file and playing buzzer) inside the Audio video subsystem will be performed making the RTC (Real time clock) Time base as a reference. Kew words: RTC, SNTP, NTP, GPS, Unicast, anycast,

1. INTRODUCTION

It is known that the time signal, which is regularly broadcast on the hour is called as analog broadcasting, so current analog broadcasting supports regular time signal broadcasting, but recent digital broadcasting cannot. So current analog broadcasting will be abolished in the days of digital broadcasting. This is because of an uncertain time delay of approximately two to four seconds, which takes place due to the digital demodulation and decoding processing of the broadcast wave. On the other hand, every in-home AV appliance is becoming multifunctional, and the system that controls these functions is also becoming larger. Regarding appliance usage, it may be planned to synchronize the operation of the devices in a system using the same time standard (i.e. time base). In such a situation, an accurate time sharing system will be required to give precise time information to each device and synchronize operation between different devices. In addition, such time information should be preferably available at low cost and be stable inside the home.

To realize this desired system, various means of capturing the necessary time information are conceivable, such as using the real time clock (RTC) of the micro processor unit (MPU) incorporated in a number of appliances. However, this alternative is low in accuracy because it is based on the principle of a cheap quartz crystal oscillation circuit. So compact SNTP server- client system is used to solve this problem, this SNTP client is synchronized with SNTP server to get standard time. SNTP server in turn uses three methods to get the standard time (universal co-ordinated time (UTC)). The following three methods are proposed in order to obtain time data for the SNTP server, they are: (1) A method of using RTC (real time clock) of microprocessor unit. (2) A method of using a radio-controlled clock; (3) A method of using the Global Positioning System (GPS); (4) A method of obtaining time data from an upper level NTP server. The first alternative, the using an RTC, is low in accuracy because it is based on the principle of a cheap quartz crystal oscillation circuit. For the second option, the radio wave clock, the number of transmitting stations and the regions that can receive the service from certain stations are limited, and further, radio waves can be received only at or near a window. For the last choice of GPS, the system will work only in places at which three or more GPS satellites are visible in the open sky, and thus it does not suit general domestic applications. Fig.1.1 shows the structure of the proposed SNTP for home use. As shown in the figure, the system is adaptable to all the three methods. When SNTP server acquires an accurate time, it will use one of those methods.

Fig 1.1 Proposed SNTP for home use


39

So I adopted third method to synchronize with standard time that is getting standard time from upper level (layer) NTP server in unicast mode. So this method is cheaper than other two methods. In the fourth method SNTP client will get standard time from SNTP server and SNTP server will in turn get standard time from NTP (Network time protocol) server. The proposed SNTP for home use in this paper is shown in below figure.

Fig 1.2 Block diagram (Unicast mode).

So this paper is divided into 5 modules those are

1. Design and Development of SNTP client. 2. Design and Development of Event management

program (EMP). 3. Installing Linux into Mini S3C2440A target board. 4. Porting Mplayer into MiniS3C2440A target board. 5. Design and development of SNTP server.

1.1 TCP/IP REFERENCE MODEL The Transmission Control Protocol/Internet Protocol (TCP/IP) suite has become the industry-standard method of interconnecting hosts, networks, and the Internet. As such, it is seen as the engine behind the Internet and networks worldwide. Although TCP/IP supports a host of applications, both standard and nonstandard, these applications could not exist without the foundation of a set of core protocols. Additionally, in order to understand the capability of TCP/IP applications, an understanding of these core protocols must be realized.. This portion begins with a discussion of the network interfaces most commonly used to allow the protocol suite to interface with the physical network media. This is followed by the protocols that must be implemented in any stack, including protocols belonging to the IP and transport layers. Finally, other standard protocols exist that might not necessarily be required in every implementation of the TCP/IP protocol suite. However, there are those that can be very useful given certain operational needs of the implementation. Such protocols include IP version 6, quality of service protocols, and wireless IP.

2. SIMPLE NETWORK TIME PROTOCOL (SNTP)

2.1 INTRODUCTION Simple network time protocol is used to synchronize computer clocks with standard time via internet. SNTP is a application layer protocol in TCP/IP protocol suite. Simple Network Time Protocol (SNTP) is a simplified access strategy for servers and clients using NTP as now specified and deployed in the

Internet. The access paradigm is identical to the UDP/TIME Protocol and, in fact, it should be easily possible to adapt a UDP/TIME client implementation, say for a personal computer, to operate using SNTP. Moreover, SNTP is also designed to operate in a dedicated server configuration including an integrated radio clock. With careful design and control of the various latencies in the system, which is practical in a dedicated design, it is possible to deliver time accurate to the order of microseconds.

SNTP Version 4 is designed to coexist with existing

NTP and SNTP Version 3 clients and servers, as well as proposed Version 4 clients and servers. When operating with current and previous versions of NTP and SNTP, SNTP Version 4 requires no changes to the protocol or implementations now running or likely to be implemented specifically for NTP or SNTP Version 4. To a NTP or SNTP server, NTP and SNTP clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP servers are undistinguishable. Like NTP servers operating in non- symmetric modes, SNTP servers are stateless and can support large numbers of clients; however, unlike most NTP clients, SNTP clients normally operate with only a single server. NTP and SNTP Version 3 servers can operate in unicast and multicast modes. In addition, SNTP Version 4 clients and servers can implement extensions to operate in anycast mode. SNTP (Simple Network Time Protocol) is basically also NTP, but lacks some internal algorithms that are not needed for all types of servers. NTP stands for Network Time Protocol, and it is an Internet protocol used to synchronize the clocks of computers to sometime reference. NTP is an Internet standard protocol originally developed by Professor David L. Mills at the University of Delaware. SNTP is a simplified version of the more general Network Time Protocol (NTP) that is commonly used in Internet servers and routers. Both SNTP and NTP share the same communication protocol and data format, the main difference being that NTP uses sophisticated algorithms that ensures a correct synchronization with multiple servers under highly variable latency data links, which is common in a worldwide network like the Internet. On the contrary, SNTP covers the synchronization with a single server and uses a simplified stateless algorithm, which makes it suitable for embedded systems in a controlled industrial environment. 2.2 SNTP OPERATING MODES SNTP Version 4 can operate in either unicast (point to point), multicast (point to multipoint) or anycast (multipoint to point) modes. 2.2.1 Unicast mode: Unicast is a one to one transmission method in which the network carries a message to one receiver, such as from a server to a LAN workstation that is a single frame or packet is sent from a single source to a single destination on a network.


40

Fig 2.1 unicast operation

A unicast SNTP client sends a request to a designated SNTP server at its unicast address and expects a reply from which it can determine the time and, optionally, the roundtrip delay and local clock offset relative to the SNTP or NTP server. 2.2.2 Multicast Mode

Fig 2.2 Multicast operation

Multicast is a one to many transmission method in which network carries a message to multiple receivers at the same time. In multicast environment, a single data frame or a single source to multiple destinations packet is copied and sent to a specific subset of nodes on the network. Multicasting is similar to broadcasting(anycast) , except that multicasting means sending to a specific group, where as broad casting implies sending to every body. A multicast SNTP server periodically sends a unsolicited message to a designated IPv4 or IPv6 local broadcast address or multicast group address and ordinarily expects no requests from SNTP clients. A multicast SNTP client listens on this address and ordinarily sends no requests. An anycast SNTP client sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address. One or more anycast SNTP servers reply with their individual unicast addresses. The SNTP client binds to the first one received, and then continues operation in unicast mode.

Multicast servers should respond to client unicast requests, as well as send unsolicited multicast messages. Multicast clients may send unicast requests in order to determine the network propagation delay between the server and client and then continue operation in multicast mode. In unicast mode, the client and server end-system addresses are assigned following the usual IPv4, IPv6 or OSI conventions. In multicast mode, the server uses a designated local broadcast

address or multicast group address. An IP local broadcast address has scope limited to a single IP subnet, since routers do not propagate IP broadcast datagrams. On the other hand, an IP multicast group address has scope extending to potentially the entire Internet. For IPv4, the IANA(Internet assigned numbers authority) has assigned the multicast group address 224.0.1.1 for NTP, which is used both by multicast servers and anycast clients. NTP multicast addresses for IPv6 and OSI have yet to be determined. Multicast clients listen on the designated local broadcast address or multicast group address. In the case of local broadcast addresses, no further provisions are necessary. In the case of IP multicast addresses, the multicast client and anycast server must implement the Internet Group Management Protocol (IGMP), in order that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group addresses assigned by the IANA. Other than the IP addressing conventions and IGMP, there is no difference in server or client operations with either the local broadcast address or multicast group address. 2.2.3 Broad cast (any cast) mode

Fig 2.3 anycast operation

Broad cast is a one to all transmission method in which the network carries a message to all devices at the same time that is from a single source to all nodes, a single data frame or packet is copied and sent to all nodes on the network. Anycast mode is designed for use with a set of cooperating servers whose addresses are not known beforehand by the client. An anycast client sends a request to the designated local broadcast or multicast group address as described below. For this purpose, the NTP multicast group address assigned by the IANA is used. One or more anycast servers listen on the designated local broadcast address or multicast group address. Each anycast server, upon receiving a request, sends a unicast reply message to the originating client. The client then binds to the first such message received and continues operation in unicast mode. Subsequent replies from other anycast servers are ignored. In the case of SNTP as specified herein, there is a very real vulnerability that SNTP multicast clients can be disrupted by misbehaving or hostile SNTP or NTP multicast servers elsewhere in the Internet, since at present all such servers use the same IPv4 multicast group address assigned by the IANA. Where necessary, access control based on the server source address can be used to select only the designated server known to and trusted by the client. The use of cryptographic authentication scheme defined in RFC-1305 is optional; however, implementers should be advised that

International Journal of Ethics in Engineering & Management EducationWebsite: www.ijeee.in

extensions to this scheme are planned specifically for NTP multicast and anycast modes. While not integral to the SNTP specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP multicast clients on the same subnet, while IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain.

In SNTP Version 3, the reference identifier was used to walk-back the synchronization subnet to the root (primary server) for management purposes. In SNTP Version 4, this feature is not available, since the addresses are longer than 32 bits. However, the intent in the protocol design was to provide a way to detect and avoid loops. A peer could determine that a loop was possible by comparing the contents of this field with the IPv4 destination address in the same packet. A SNTP Version 4 server can accomplish the same thing by comparing the contents of this field with the low order 32 bits of the originate timestamp in the same packet. There is a small possibility of false alarm in this scheme, but the false alarm rate can be minimized by randomizing the low order unused bits of the transmit timestamp. 2.3 SNTP TIME STAMP FORMAT SNTP uses the standard NTP timestamp format described in RFC-1305 and previous versions of that document. In conformance with standard Internet practice, NTP data are specified as integer or fixed-point quantitienumbered in big-endian fashion from 0 starting at the left, or high-order, position. Un-less specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0. Since NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established. NTP timestamps are represented as a 64-bit unsigned fixedpoint number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the nonorder can be set to 0. It is advisable to fill the nonlow order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic round off errors and as a means of loop detection and replay detection (see below). One way of doing this is to generate a random bit string in a 64word, then perform an arithmetic right shift a number of bits equal to the number of significant bits of the timestamp, then add the result to the original timestamp. This format allows convenient multiple-precision arithmetic and conversion to UDP/TIME representation (seconds), but does complicate the conversion to ICMP Timestamp message represwhich is in milliseconds. The maximum number that can be represented is 4,294,967,295 seconds with a precision about 200 picoseconds, which should be adequate for even the most exotic requirements.

Ethics in Engineering & Management EducationWebsite: www.ijeee.in (ISSN: 2348-4748, Volume 1, Issue 1, January 2014

41

to this scheme are planned specifically for NTP While not integral to the SNTP

specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a

server with a number of dependent SNTP multicast clients on the same subnet, while IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain.

In SNTP Version 3, the reference identifier was often back the synchronization subnet to the root

(primary server) for management purposes. In SNTP Version 4, this feature is not available, since the addresses are longer than 32 bits. However, the intent in the protocol design was to

e a way to detect and avoid loops. A peer could determine that a loop was possible by comparing the contents of this field with the IPv4 destination address in the same packet. A SNTP Version 4 server can accomplish the same

s of this field with the low order 32 bits of the originate timestamp in the same packet. There is a small possibility of false alarm in this scheme, but the false alarm rate can be minimized by randomizing the low

SNTP uses the standard NTP timestamp format described 1305 and previous versions of that document. In

conformance with standard Internet practice, NTP data are point quantities, with bits

endian fashion from 0 starting at the left, or less specified otherwise, all quantities

are unsigned and may occupy the full field width with an Since NTP timestamps are

shed data and, in fact, represent the main product of the protocol, a special timestamp format has been established.

bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900.

the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low

It is advisable to fill the non-significant low order bits of the timestamp with a random, unbiased bit-

systematic round off errors and as a means of loop detection and replay detection (see below). One way of doing this is to generate a random bit string in a 64-bit word, then perform an arithmetic right shift a number of bits

icant bits of the timestamp, then This format allows

precision arithmetic and conversion to UDP/TIME representation (seconds), but does complicate the conversion to ICMP Timestamp message representation, which is in milliseconds. The maximum number that can be represented is 4,294,967,295 seconds with a precision about 200 picoseconds, which should be adequate for even the most

2.4 SNTP Timestamp format Note that, since some time in 1968 (second 2,147,483,648) the most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296). Should NTP or SNTP be in use in 2036, some external means will be necessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136 years). There will exist a 200-ignored, every 136 years when the 64by convention is interpreted as atimestamp. As the NTP timestamp format has been in use for the last 17 years, it remains a possibility that it will be in use 40 years from now when the seconds field overflows. As it is probably inappropriate to ar-chive NTP times0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968is reckoned from 0h 0m 0s UTC on 1 January 1900. If bnot set, the time is in the range 2036reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is not a leap year. Note also that leap seconds are not counted in the reckoning. 2.4 SNTP MESSAGE FORMATBoth NTP and SNTP are clients of the User Datagram Protocol (UDP), which itself is a client of the Internet Protocol (IP) . The UDP port number assigned to NTP is 123, which should be used in both the Source Port and Destination Port fields in the UDP header. The remaining UDP header fields should be set as described in the specification.Below is a description of the NTP/SNTP Version 4 message format, which follows the IP and UDP headers.

Fig 2.5 SNTP message format

Ethics in Engineering & Management Education , Volume 1, Issue 1, January 2014)

2.4 SNTP Timestamp format

some time in 1968 (second 2,147,483,648) the most significant bit (bit 0 of the integer part) has been set and

bit field will overflow some time in 2036 (second 4,294,967,296). Should NTP or SNTP be in use in 2036, some

ecessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136

-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable

As the NTP timestamp format has been in use for the last 17 years, it remains a possibility that it will be in use 40 years from now when the seconds field overflows. As it is

chive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036- 2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is not a leap year. Note also that leap seconds are not counted in the

SNTP MESSAGE FORMAT Both NTP and SNTP are clients of the User Datagram

which itself is a client of the Internet Protocol (IP) . The UDP port number assigned to NTP is 123, which should be used in both the Source Port and Destination Port ields in the UDP header. The remaining UDP header fields

should be set as described in the specification. Below is a description of the NTP/SNTP Version 4 message format, which follows the IP and UDP headers.

Fig 2.5 SNTP message format


42

2.5 SNTP APPLICATION Simple Network Time Protocol (SNTP) over Ethernet as a standard way to synchronize a set of substations with a time server. SNTP is a simplified version of the more general Network Time Protocol (NTP) that is commonly used in Internet servers and routers. Both SNTP and NTP share the same communication protocol and data format, the main difference being that NTP uses sophisticated algorithms that ensures a correct synchronization with multiple servers under highly variable latency data links, which is common in a world wide network like the Internet. On the contrary, SNTP covers the synchronization with a single server and uses a simplified stateless algorithm, which makes it suitable for embedded systems in a controlled industrial environment. Nevertheless, a SNTP client may communicate with either a SNTP server or a full NTP server.

3. SNTP CLIENT 3.1 INTRODUCTION A SNTP client can operate in multicast mode, unicast mode or anycast mode. In multicast mode, the client sends no request and waits for a broadcast from a designated multicast server. In unicast mode, the client sends a request to a designated unicast server and expects a reply from that server. In anycast mode, the client sends a request to a designated local broadcast or multicast group address and expects a reply from one or more anycast servers. The client uses the first reply received to establish the particular server for subsequent unicast operations. Later replies from this server (duplicates) or any other server are ignored. Other than the selection of address in the request, the operations of anycast and unicast clients are identical. Requests are normally sent at intervals from 64 s to 1024 s, depending on the frequency tolerance of the client clock and the required accuracy.

A unicast or anycast client initializes the NTP message header, sends the request to the server and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all of the NTP header fields shown above can be set to 0, except the first octet and (optional) Transmit Timestamp fields. In the first octet, the LI field is set to 0 (no warning) and the Mode field is set to 3 (client). The VN field must agree with the version number of the NTP/SNTP server; however, Version 4 servers will also accept previous versions. To calculate the roundtrip delay d and local clock offset t relative to the server, the client sets the transmit timestamp in the request to the time of day according to the client clock in NTP timestamp format. The server copies this field to the originate timestamp in the reply and sets the receive timestamp and transmit timestamp to the time of day according to the server clock in NTP timestamp format. When the server reply is received, the client determines a Destination Timestamp variable as the time of arrival according to its

clock in NTP timestamp format. The following table summarizes the four timestamps.

Table 3.1 Time stamps

Fig 3.1: Operation of SNTP

The roundtrip delay d and local clock offset t are defined as

d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.

Using the calculated offset, the client can correct its local clock to match the server time. Software implementations of SNTP typically achieve time synchronization within a microsecond with respect to the server. The precision of the SNTP synchronization can be largely improved by doing the time-stamping operation in lower layers, therefore some operating system kernels like Linux of FreeBSD support SNTP processing in the kernel. This way, precision may reach some tens of microseconds. The highest precision in the time-stamping operation is only achievable if done by the Ethernet device hardware as soon as the packets arrive or leave the interface.


43

3.2 FLOW CHART FOR SNTP CLIENT:

Fig 3.2 Flowchart for SNTP client

4. SNTP SERVER

4.1 INTRODUCTION A SNTP Version 4 server operating with either a NTP or SNTP client of the same or previous versions retains no persistent state. Since a SNTP server ordinarily does not implement the full set of NTP algorithms intended to support redundant peers and diverse network paths, a SNTP server should be operated only in conjunction with a source of external synchronization, such as a reliable radio clock or telephone modem. In this case it always operates as a primary (stratum 1) server.

Structure of Domestic SNTP server is shown in below figure.

Fig 4.1 Structure of domestic SNTP server.

Fig 4.2 Behavior of SNTP server

So SNTP server is responsible for getting standard time(UTC) from remote NTP server and wait for giving reply to SNTP client, as soon as SNTP client sends request to SNTP server it gives reply to SNTP client until then it keeps on waiting in a infinite loop. Finally in- home audio /video devices synchronized with UTC time through SNTP server. Structure of Domestic SNTP server- client system is shown in below figure

Fig 4.3 Structure of Domestic SNTP server- client system

4.2 SNTP server operations A SNTP server can operate in unicast mode, anycast mode, multicast mode or any combination of these modes. In unicast and anycast modes, the server receives a request (mode 3), modifies certain fields in the NTP header, and sends a reply (mode 4), possibly using the same message buffer as the request. In anycast mode, the server listens on the designated


44

local broadcast or multicast group address assigned by the IANA, but uses its own unicast address in the source address field of the reply. Other than the selection of address in the reply, the operations of anycast and unicast servers are identical. Multicast messages are normally sent at poll intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy.

In unicast and anycast modes, the VN and Poll fields

of the request are copied intact to the reply. If the Mode field of the request is 3 (client), it is set to 4 (server) in the reply; otherwise, this field is set to 2 (symmetric passive) in order to conform to the NTP specification. This allows clients configured in symmetric active (mode 1) to interoperate successfully, even if configured in possibly suboptimal ways. In multicast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field set to the nearest integer base-2 logarithm of the poll interval. In unicast and anycast modes, the server may or may not respond if not synchronized to a correctly operating radio clock, but the preferred option is to respond, since this allows reachability to be determined regardless of synchronization state. In multicast mode, the server sends broadcasts only if synchronized to a correctly operating reference clock. The remaining fields of the NTP header are set in the following way. Assuming the server is synchronized to a radio clock or other primary reference source and operating correctly, the LI field is set to 0 and the Stratum field is set to 1 (primary server); if not, the Stratum field is set to 0 and the LI field is set to 3. The Precision field is set to reflect the maximum reading error of the local clock. For all practical cases it is computed as the negative of the number of significant bits to the right of the decimal point in the NTP timestamp format. The Root Delay and Root Dispersion fields are set to 0 for a primary server; optionally, the Root Dispersion field can be set to a value corresponding to the maximum expected error of the radio clock itself. The Reference Identifier is set to designate the primary reference source.

The timestamp fields are set as follows. If the server

is unsynchronized or first coming up, all timestamp fields are set to zero. If synchronized, the Reference Timestamp is set to the time the last update was received from the radio clock or modem. In unicast and anycast modes, the Receive Timestamp and Transmit Timestamp fields are set to the time of day when the message is sent and the Originate Timestamp field is Copied unchanged from the Transmit Timestamp field of the request. It is important that this field be copied intact, as a NTP client uses it to avoid replays. In multicast mode, the Originate Timestamp and Receive Timestamp fields are set to 0 and the Transmit Timestamp field is set to the time of day when the message is sent.

4.3 Design and development of SNTP server 4.3.1 Flow chart for SNTP server

5. EXPERIMENTAL RESULTS 5.1SNTP CLIENT AND EMP RESULTS SNTP client is responsible for getting time from SNTP server whose IP address is 183.82.165.21 and calculate offset and delay based on server time for each poll and calculate total delay and offset, then set client side RTC(real time clock) by adding offset and delay to current RTC. ./sntpclient -dv –p 6 –t 10 server 183.82.165.21, here poll times is 6 SNTP client poll SNTP server six times.


Table 5.1 SNTP client output

Fig 5.1 SNTP client output

POLL NO Offset DelayPoll number 1 -2.478854 5.04659Poll number 2 0.022268 10.05220Poll number 3 0.019581 10.05026Poll number 4 0.018234 10.05104Poll number 5 0.017068 10.05235Poll number 6 0.014407 10.05061

Total -0.061795 9.89474


45

.1 SNTP client output

.1 SNTP client output

Fig 5.2 SNTP client and EMP output. 5.2 SNTP SERVER RESULTS5.1SNTP CLIENT AND EMP RESULTS SNTP server is responsible for getting time from NTP server whose DNS is “pool.ntp.org” and calculate offset and delay based on server time for each poll and calculate total delay and offset, then set SNTP server side RTC(real time clock) by adding total offset and delay to current RTC. ./sntpserver -dv –p 6 –t 10 server pool.ntp.org, here poll times is 5 SNTP server poll NTP server five times

Table 5.2 SNTP server outp

Delay 5.04659 10.05220 10.05026 10.05104 10.05235 10.05061 9.89474

POLL NO Offset Poll number 1 0.005350Poll number 2 0.005402Poll number 3 0.005828Poll number 4 0.005589Poll number 5 0.005635 Total 0.005615


.2 SNTP client and EMP output.

.2 SNTP SERVER RESULTS P RESULTS

responsible for getting time from NTP server whose DNS is “pool.ntp.org” and calculate offset and delay based on server time for each poll and calculate total delay and offset, then set SNTP server side RTC(real time clock) by

to current RTC.

t 10 server pool.ntp.org, here poll times is 5 SNTP server poll NTP server five times

.2 SNTP server outp

Offset Delay 0.005350 0.05774 0.005402 0.05756 0.005828 0.05811 0.005589 0.05785 0.005635 0.05739 0.005615 0.05762


Figure 5.3 SNTP server results

Figure 5.4 SNTP server output


46

server results

.4 SNTP server output

6. CONCLUSION

This paper has implemented a compact time sharing system for home use applying the Simple Network Time Protocol. The compact SNTP server/client system for home appliances was developed as extension of an SNTP client application. The developed system can obtain the NTP servers. For verification, the developed system operated on a Linux operating system, Kernel 2.6 version with a 32RISC ARM processor. The SNTP client obtained a time signal every 15 minutes from the prototype SNTP server. Thmeasured error (offset) in this case was about 0.005615micro seconds(µs) for SNTP server side and seconds (µs)for SNTP client side.

REFERENCES [1]. Yuta Uesugi, Shuji Sugiyama, Takako Nonaka,

Server and Client System for Home Use”, IEEE International Symposium on Consumer Electronics 2009.

[2]. D. Mills, RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,” http://tools.ietf.org/html/rfc2030”, browsed atMarch 27, 2009.

[3]. Yuta Uesugi, Takako Nonaka, Tomohiro Hase, “Time Sharing System for In-home Electric Appliances Using Simple Network Time Protocol”, IEEE International Symposium on Consumer Electronics 2008.

[4]. D. L. Mills, Network Time Protocol (Version 3) Implementation and Analysis, RFC 1305, Status: Draft Standard. March 2006.

[5]. J.Viejo, J.Juan, M.J.Bellido, E.ostua, A.Millan, P.RuizA.Munoz, and.guerrero “Design and Implementation of a SNTP client on FPGA.

About the authors:

P. Aruna Sreee received Electronics and Instrumentation Engineeringand M.Tech JNTU Hyderabad. working as an AssistantECE department at RVR Institute of Engineering & TeUp to now

international conferences, Workshops.Embedded systems, VLSI, Control and Instrumentation

Kumar. KeshamoniB.Tech in Electronics & CommunicatioUniversity of JNTU, his M.Tech in VLSI Design from the University of JNTU-Hyderabad. He is currently the Asst. Professor in Department of Electronics & Communication Engineering, RVR Institute of Engineering in University of the JNTU

Hyderabad. Kumar. Keshamoni is Chair of World Committees Associate Member of UACEE (Universal Association of


CONCLUSION

has implemented a compact time sharing system for home use applying the Simple Network Time Protocol. The compact SNTP server/client system for home appliances was developed as extension of an SNTP client application. The developed system can obtain the time from upper layer NTP servers. For verification, the developed system operated on a Linux operating system, Kernel 2.6 version with a 32-bit RISC ARM processor. The SNTP client obtained a time signal every 15 minutes from the prototype SNTP server. The measured error (offset) in this case was about 0.005615micro seconds(µs) for SNTP server side and -0.061795 micro seconds (µs)for SNTP client side.

REFERENCES

Yuta Uesugi, Shuji Sugiyama, Takako Nonaka, Tomohiro Hase “SNTP Server and Client System for Home Use”, IEEE International Symposium on Consumer Electronics 2009. D. Mills, RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,” http://tools.ietf.org/html/rfc2030”, browsed at

Yuta Uesugi, Takako Nonaka, Tomohiro Hase, “Time Sharing System home Electric Appliances Using Simple Network Time Protocol”,

IEEE International Symposium on Consumer Electronics 2008. D. L. Mills, Network Time Protocol (Version 3) Specification, Implementation and Analysis, RFC 1305, Status: Draft Standard. March

J.Viejo, J.Juan, M.J.Bellido, E.ostua, A.Millan, P.Ruiz-de-clavijo, A.Munoz, and.guerrero “Design and Implementation of a SNTP client

Aruna Sreee received B.Tech degree in Electronics and Instrumentation Engineering from the University of JNTU and M.Tech in in Embedded Systems in JNTU Hyderabad. I am currently working as an Assistant. Professor in ECE department at RVR Institute of Engineering & Technology, Hyderabad. Up to now attended several national and

international conferences, Workshops. Research interests in Control and Instrumentation

Kumar. Keshamoni obtained his B.Tech in Electronics & Communication Engineering from the University of JNTU, his M.Tech in VLSI Design from the University of

Hyderabad. He is currently the Asst. Professor in Department of Electronics & Communication Engineering, RVR Institute of Engineering in University of the JNTU-

Hyderabad. Kumar. Keshamoni is Chair of World Committees Associate Member of UACEE (Universal Association of


47

Computer & Electronics Engineers), Member of IEEE Vehicle Community, Member of IAENG and an Advisory Board of WATT (World Association of Technology Teachers). He is also on the Advisory & Editorial Board of IJETAE, an Associate Editor of IJPRET, Editor of IJOART, Editorial Board & Review Committee of IJSER, an Editorial & Review Board of IJTRA, Editor, writer & Peer Reviewer of edition International Publisher, Peer Reviewer of AJET, Review Committee of IJERT, Editorial & Review Board of IJOAR, Review Board of IJASCSE, Advisory& Editorial Board of IJRDET, Editorial Board of IJEERT Member of IAENG, Writer& Review Board of IJEVS, Advisory Board of WRJET, Scientific Committee & Editorial Review Board on Engineering and Physical Sciences of WASET and Editorial Board of IAASSE. He is also working as a member for 10 International conference committees. He has published about 20 Research articles in International Journals and 5 papers in National and International Conferences and attended several National, International Conferences, and Workshops & Faculty Development Programs in different organizations. His recent research interests lie in the area of Embedded, VLSI Design, Digital Signal Processing and Nanotechnology.

International Journal of Ethics in Engineering & Management Education TIME BASED EVENT MANAGEMENT WITH SNTP CLIENT AND SERVER

Documents