text:
A step toward realistic evaluation of high-speed TCP protocols
Sangtae Ha+, Yusung Kim$, Long Le+, Injong Rhee+, and Lisong Xu*
+Department of Computer Science
North Carolina State University
Raleigh, NC 27699
*Department of Computer Science and Engineering
University of Nebraska, Lincoln
Lincoln, NE 68588-0115
$Department of Computer Science
Korean Advanced Institute of Science and Technology
Taejon, South Korea.
Congestion control is an important component of a transport protocol in a packet-switched shared network. The congestion control algorithm of the widely used transport protocol TCP is responsible for detecting and reacting to overloads in the Internet and has been the key to the Internet's operational success. However, as link capacity grows and new Internet applications with high-bandwidth demand emerge, TCP performance is unsatisfactory, especially on high-speed and long distance networks. The main reason for this is the conservative behavior of TCP in adjusting its congestion window that governs the senders' transmission rates.
A number of solutions have been proposed to remedy the aforementioned problem of TCP by changing the way in which TCP adapts its congestion window: BIC TCP [1], CUBIC [2], FAST [3], HSTCP [4], HTCP [5], STCP [6], TCP-Westwood [10], LTCP [26] and TCP-Africa [11]. These new protocols promise to improve TCP performance on high-speed networks significantly and are hence usually called TCPs for high-speed networks.
While the design of TCPs for high-speed networks has received a considerable amount of interest, far less attention has been paid to thorough evaluations and their comparison of these protocols. For example, Internet measurement studies showed complex behaviors and characteristics of Internet traffic [14, 15, 20]. Unfortunately, existing evaluation work [8] did not capture these behaviors in their testing environments. Since congestion control algorithms are very sensitive to environmental variables such as background traffic and propagation delays, realistic performance evaluations of TCPs for high-speed networks require creating realistic network environments where these protocols are likely to be used.
There are many factors constituting a network environment. Most frequently used factors often captured for creating a "realistic" testing environment include static end-to-end characteristics such as (1) bottleneck bandwidth, (2) round-trip times of protocol flows being observed, (3) the network topology over the path that protocol flows of interest travel through, and (4) queue size at the bottleneck link. These factors are more or less static and do not change over the course of the experiment. What is missing in most of existing evaluation work are the considerations of (1) what the protocol flows of interest dynamically (i.e., in a time-varying manner) experience in the middle of the network path, namely the dynamic statistical properties of "background traffic" over the intermediate links and (2) the impact of background traffic to the statistical properties of such traffic. Most of these dynamic characteristics cannot be measured at end points. Yet they can greatly influence the behaviors of the protocol flows being observed at the end points.
There are several reasons why background traffic is important in protocol testing. First, network environments without any randomness in packet arrivals and delays are highly susceptible to the phase effect [25], a commonly observed simulation artifact caused by extreme synchronization of the network flows on the end-to-end path. A good mix of background traffic with diverse arrival patterns and delays reduce the likelihood of the phase effect. Second, a high degree of statistical multiplexing is often assumed in protocol design. For instance, the inventors of HSTCP and STCP rely on statistical multiplexing for faster convergence. So criticizing these protocols for slow or no convergence under environments without background traffic as done in [8] is unnecessary. As today's Internet contains a high degree of statistical multiplexing, testing with no or little background traffic does not capture the actual intended behaviors of protocols in production networks. Third, as much as background traffic can influence the behavior of the protocol flows being observed, the statistical behaviors of this "passing-through" aggregate traffic can also be significantly altered by the nature of the protocols flows being tested. Thus, measuring the statistical properties of the background traffic in the middle of the network enables us to study the impact. This impact is important from the perspective of fairness or backward compatibility of the protocols.
In this work, we have created an experimental network model that captures some of the complex characteristics of background traffic [14, 15, 20]. We use our network model to evaluate a large collection of recently proposed TCPs for high-speed networks: BIC, CUBIC, FAST, HSTCP, H-TCP, and STCP. While we do not claim that we have the most realistic experimental network model, we believe that our work is a right step toward improving experimental methodologies for evaluating network protocols. Since we make no claim about the realism of our background traffic mix, this work-in-progress report has a modest goal of simply contrasting protocol behaviors observed from two different environments created with and without background traffic. It is well known [25] that the presence of background traffic in a network experiment can change the behavior of the protocols being tested. However, few studies on exactly how high-speed TCP flows can be impacted by the background traffic and what aspects of background traffic can change the behaviors of the TCP flows in what ways, and vice versa. Identifying these factors is important as the testing environments exhibiting these factors can be good candidates for more "intelligent" base testing cases and scenarios.
Our future work will evolve into testing protocols with more realistic background traffic. We plan to use some of the existing traffic generators such as Tmix [24] and Harpoon [23] that rely on real network traces as seeds for generating synthetic network traffic, and plan to create a standard set of network testing environments where the network community can test and compare protocol behaviors.
Floyd [13] proposes a framework for evaluating congestion control algorithms. The framework includes a number of metrics to be considered such as throughput, packet loss rates, delays, and fairness as well as a range of network environments. Along the same line, Wei et al. [12] propose that the networking community establishes a TCP benchmark suite to leverage comparative performance evaluations of TCP variants. The benchmark includes various scenarios for realistic performance evaluations such as heavy-tail file size distributions and ranges of propagation delays. These frameworks illustrate the need for realistic performance evaluations of new congestion control algorithms and accentuate the motivation for our work and existing evaluation work that we briefly review below.
Bullot et al. [7] compare the performance of TCP New Reno with HSTCP, FAST, STCP, HSTCP-LP, H-TCP, and BIC on high-speed production networks. They report that TCP-SACK gives poor performance and most TCP variants for high-speed networks deliver significant improvement over TCP-SACK. Although Bullot et al.'s results are very informative, as their experiments are performed over a real production network path, they don't have control over background traffic on the network. Only UDP background traffic is added and the impact of network environments created by various mixes of background traffic on protocol behaviours are not considered.
Li et al. [8] perform experiments for STCP, HSTCP, BIC, FAST, and H-TCP in a lab network. They noted that most protocols, especially FAST, STCP, HSTCP and BIC, exhibit substantial unfairness in their experiments and highlighted the good performance of HTCP. They do not have any background traffic in their experiments.
3.1 Testbed Setup
The experimental network that we used to perform experiments for TCPs for high-speed networks is shown in Figure 1. At each edge of the network are four machines that have identical hardware configurations. Two machines are used as TCP senders and run iperf to simulate high-performance applications that have the demand to transmit a large amount of data to two other machines functioning as TCP receivers on the other side of the network. The TCP senders run a modified version of Linux 2.6.13 kernel that includes the implementations of new congestion control algorithms for high-speed networks.
Figure 1: Experimental network setup.
As pointed out by Li et al. [8], existing implementations of various congestion control algorithms often make changes to parts of the TCP stack that are not directly related to the congestion control algorithm in order to improve their overall performance. To be fair to all congestion control algorithms, we run a modified version of Linux 2.6.13 kernel that separates the implementation of congestion control algorithms from the standard TCP stack (with the exception of FAST that has an implementation in Linux kernel 2.4 because FAST is not yet publicly available in Linux kernel 2.6). Further, we modified the SACK implementation to remove inefficiencies of the standard SACK implementation. Our improved SACK implementation is equally effective for all congestion control algorithms.
At the core of the network are two FreeBSD 5.2.1 machines running dummynet software [21]. These machines are carefully tuned to be capable of forwarding traffic up to 600 Mbps consistently. The dummynet software is used in the first router to control the bandwidth and buffer size of the bottleneck link in the network. The bandwidth of the bottleneck link is configured to be 400 Mbps. Unless mentioned otherwise, the buffer size of the bottleneck link is fixed to the maximum of 2 Mbytes. While various rules of thumb recommend that the buffer size be proportional to the bandwidth delay product (BDP), we follow a more practical approach where the buffer size cannot be less than some reasonable capacity. We test the protocols with a smaller router buffer size than BDP because this is a likely trend in high-speed routers. This trend is in line with recent research results showing that the buffer size of a bottleneck link with a high degree of multiplexing of TCP connections can be much less than the bandwidth delay product [16, 17].
TCP-SACK is used as the baseline TCP for comparison and fairness tests and also for generating background traffic.
3.2 Model for propagation delays
An extension of dummynet is used in the second router to assign per-flow delays to long-lived as well as short-lived background traffic flows. This configuration gives all packets from a flow the same amount of delay randomly sampled from a distribution. We use the distribution of RTT obtained from a measurement study [14].
3.3 Models for background traffic
Congestion control protocols for high-speed networks are unlikely to run alone in dedicated networks. Thus, we need to generate some background traffic to make our results realistic as in real-world scenarios. Two types of flows are used to generate background traffic: long-lived and short-lived. The long-lived flows are generated by iperf and are used to simulate regular long-lived TCP flows such as ftp. The amount of traffic generated by these flows is controlled by the number of iperf connections. But in all of our experiments, we fix the number of these connections for convenience. This parameter needs to be varied to perform more comprehensive study. Short-lived flows are used to simulate web sessions and are generated using Lognormal (Body) and Pareto (Tail) distribution for their file sizes [12, 15, 20]. The inter-arrival time between two successive short-lived flows follows an exponential distribution and is used to control the amount of short-lived flows [12, 20]. The chosen distributions of file sizes and inter-arrival times are taken from Internet traffic characteristics [12, 20]. Further, we also generate reverse traffic consisting of both short-lived and long-lived flows to achieve the effects of ACK compression [22] and to reduce the phase effect. The maximum receiver window size of these long and short-lived TCP flows used for background traffic is set to the default 64KB. This is because most TCP stacks used in the Internet have the default receiver buffer size of 64KB. Our background traffic, along with the model for propagation delays described above, allows us to create workloads containing some of the statistical properties observed in real-world scenarios for high-speed TCP.
Each experiment runs for 1200 seconds. The long-lived and short-lived background flows start at time 0. If we have two high-speed TCP flows in each experiment, the first flow starts at 30 seconds and the second flow starts at 130 seconds. We took the measurement after the first 135 seconds to eliminate the effect of the start-up phase. We perform a suite of experiments where propagation delays for the two high-speed TCP flows are set to 16, 42, 82, 162, and 324 milliseconds to simulate different network scenarios. Note that while the propagation delays for high-speed TCP flows are set to these values, propagation delays for background traffic are randomly sampled from our propagation delay model described in section 3. Actual delays that a packet experiences depend on the buffer size and the amount of traffic at the time of packet transmission. We simulate scenarios where various high-speed TCP flows either experience the same or different propagation delays. For each of the chosen propagation delays, we perform experiments with and without background traffic to contrast experimental results and protocol behaviors between these scenarios. The congestion control protocols for high-speed networks are evaluated based on the following properties: fairness, convergence time, RTT fairness, TCP friendliness, link utilization, stability of throughput, and packet loss rates.
We measure the utilization ratio of the bottleneck link capacity. In our current test setup, 400Mbps is the maximum link capacity and about 95% utilization of this capacity seems the maximum capacity utilization observed at the bottleneck router with any protocol we tested. We conjecture that 5% utilization loss is due to the software implementation of the router. We found that the utilization ratio shows high sensitivity to the queue size of the bottleneck router, the characteristics of background traffic and the behavior of protocols being tested.
Below Figure 2 shows the results of experiments where we run one flow of a high-speed TCP protocol together with one flow of regular TCP-SACK (SACK). In each experimental run, both flows have the same RTT. We vary the RTT from 16ms to 324ms. The buffer size of the bottleneck router is fixed to 2Mbytes. With a 324ms RTT, this buffer size amounts to roughly 12% of bandwidth and delay product (BDP) of the network. All protocols drop their utilization below 65% in the 324ms RTT run. This is because the window size (cwnd) and its variance of the high speed TCP flow begin tested (except for TCP-SACK) are too large to be accommodated by such buffer. With 324ms RTT, the maximum window size of high speed flows is larger than 10,000 packets (which is around 20Mbytes).
Figure 2: Link utilization ratio when buffer size is limited to 2Mbps, one TCP-SACK, and one TCP variant flow, 400Mbps bottleneck capacity. We vary RTT from 16ms to 324ms. Each data point represents the average link utilization of each run. (More information about this experiment)
To our surprise, as we add background traffic (both short and long lived flows) to the same experiment, the utilization ratio has dramatically changed. Figure 3 shows the utilization results of the same experiment as in Figure 2 but with background traffic.
Figure 3: Link utilization. The same experiment as the above but with background traffic. (More information about this experiment)
The utilization ratio with 324ms RTT has enhanced up to 90-95% for HSTCP, CUBIC, BIC, FAST and TCP-SACK. This change in utilization confirms the recent work by Appenzeller et al. [16] that the high statistical multiplexing in the bottleneck link (i.e., high randomness) permits use of small buffers. Note that there is enough background traffic to consume all the link capacity even without high speed TCP flows. These background flows are generated by TCP and their transmission rates are elastic to the amount of traffic in the network to the extent limited by the maximum allowed by 64KB receiver buffer size.
Even with background traffic, the utilization of HTCP, FAST and STCP with RTTs 160ms and 324ms is significantly lower than that of other protocols. We conjecture that this problem is related to the inherent protocol behavior of HTCP in the way that HTCP ties its window reduction to the estimated buffer size of the network. For STCP, it is being simply too aggressive. For FAST, its behavior becomes less predictable with presence of background traffic due to noise in RTT estimation. We later examine these behaviors of HTCP, FAST and STCP. Figures 4 and 5 below show two different types of experiments, all with background traffic: (1) two flows of a TCP variant with the same RTT and (2) two flows of a TCP variant, but the RTT of one flow is set to 164ms and the RTT of the other flow is varied from 16ms to 164ms.
Figure 4: Link utilization with background traffic, two flows of a high speed TCP variant with the same RTT. (More information)
Figure 5: Link utilization with background traffic, two flows of a high-speed TCP variant. The RTT of one flow is set to 162ms and the RTT of the other flow is varied from 16ms to 164ms. (More information)
Both experiments in Figures 4 and 5 are conducted with two flows of the same TCP variant. But the difference lies in the RTT values of each flow. Thus, when they have the same RTT, their average transmission rate is approximately the same (if they ensure intra-protocol fairness) and also lower than when they have different RTTs in which case one flow tends to have a higher transmission rate than the other. We observe that the utilization of HTCP is generally lower than that of the other protocols. Note that the experiments inject enough background traffic to consume the entire network capacity even without high speed flows. Especially in the second experiment (Figure 5), HTCP shows lower utilization even with low RTTs. This suggests that HTCP may also have lower utilization when it competes with heterogeneous traffic of different RTTs.
Figure 6 shows the average utilization of each traffic type measured in the second experiment when one HTCP flow with RTT 164ms (red line) competes with the other HTCP flow with RTT 42ms (green line), which corresponds to the 42ms point in Figure 5 above. The high level of fluctuations in the total link utilization (marked light yellow line) is clearly visible.
Figure 6: the average utilization of each traffic type measured at a second interval when one HTCP flow with RTT 164ms competes with the other HTCP flow with RTT 42ms (the 42ms point in Figure 5 above). Light greenish yellow lines are the total utilization; red lines are the HTCP flow with 164ms; green lines are the HTCP flow with 42ms; blue lines are long-lived flows, and purple lines are short-lived flows. Light green: total utilization, Red line: HTCP with 162ms, Green line: HTCP with 42ms, Blue line: long-lived background TCP flows, Purple line: short-lived TCP flows. More information)
Figures 7 (a) and (b) show the throughput measured at the router for the runs with CUBIC flows and STCP flows respectively. All the experiment setups are the same as in Figure 6. Both cases show much improved stability compared to that of HTCP.
(a) CUBIC (more information)
(b) STCP (more information)
Figure 7: The same metric in the same experimental environments as in Figure 6 except the high-speed flows are replaced by those of CUBIC and those of STCP respectively. The light yellow-green lines (the top lines) indicate the total utilization of the bottleneck link. Both achieve very good link utilization.
The different utilization ratios of various high-speed protocols can be explained as follows. We found that protocols that increase their transmission rate slowly (or at a reduced increment) near the saturation point tend to have high utilization. CUBIC, BIC and FAST have this feature (the poor performance of FAST is not related to this feature, but to its dependency to RTT, we conjecture). The smaller increments near the saturation point increase the congestion epoch and result in fewer self-induced losses. Furthermore, they reduce the chance of synchronized losses. When a high rate flow with a long RTT overflows the buffer, the overflow may last for some time (at the minimum for the duration of RTT). During this period, competing flows arriving to the same buffer may also experience the same losses. Most protocols except FAST, BIC and CUBIC tend to have a convex window growth function whose window increments are the largest at the time of packet losses. A large number of overflown packet could prolong the length of overflow and cause severe loss synchronizations. On the other hand, FAST, BIC and CUBIC have a concave growth function, so the window growth rate at the time of loss is the smallest, thus tend to have reduced synchronized losses. Below we examine this behavior of protocols in more detail.
(a) one HSTCP flow with one TCP flow
(b) two HSTCP flows with the same RTT
Figure 8: Loss synchronization of HSTCP flows. (a) The same setup as in Figure 3 with 162ms RTT, and (b) the same setup as in Figure 5, but two HSTCP flows have the same RTT of 162ms.
In Figure 8, we find that whenever the dominating HSTCP flow has a loss, the other flows have losses. This is visible from the timings of fluctuations in the total utilization being matched with those in the dominating flow (dark green line) and the amount of utilization reduction is bigger than the rate reduction by one HSTCP flow. The blue line is the total throughput used by the long-lived background TCP flows.
(a) one STCP flow with one TCP flow
(b) two STCP flows with different RTTs
Figure 9: Loss synchronization of STCP flows. (a) The same setup as in Figure 3 with 162ms RTT, and (b) the same setup as in Figure 5, but two STCP flows have the same RTT of 162ms.
In Figure 9 (a), we observe that this problem is even worse with STCP. This is because just before its drop, its increment is very large as it adopts an exponential growth function, overflowing the buffers. This has effect on the other flows and also itself. It has multiple cascaded losses and background traffic (which does not occupy even a significant portion of the bandwidth) also experiences packet losses (blue line drops when the green line drops) at the same time – loss synchronization is severe. In Figure 9 (b), a similar phenomenon is observed here. In this case, the two STCP flows take too much bandwidth. The synchronized reduction between STCP and the other flows is hard to see because the bandwidth occupied by the other flows is very small (STCP taking most of bandwidth). But the amount of total utilization reduction at each time of loss is larger than one STCP flow's reduction.
(a) one BIC flow with one TCP flow
(b) two BIC flows with different RTTs
Figure 10: Loss synchronization of BIC flows. (a) The same setup as in Figure 3 with 162ms RTT, and (b) the same setup as in Figure 5, but two BIC TCP flows have the same RTT of 162ms.
BIC shows improved utilization in both cases of Figure 10. We still see some synchronization in Figure 10 (a), but it is not as severe as in HSTCP and STCP.
(a) one CUBIC flow with one TCP flow (more information)
(b) two CUBIC flows with different RTTs (more information)
Figure 11: Loss synchronization of CUBIC flows. The same setup as in Figure 10.
CUBIC shows a slight improvement over BIC. The amount of synchronization is very small clearly visible from comparison between Figures10, and 11. The low utilization at the beginning of Figure 11 (a) before 150 seconds is due to the aggressiveness of slow start from the joining TCP-SACK flow causing the high speed flow to have several cascaded losses while TCP-SACK is not fast enough (after slow start) to consume the available bandwidth.
We measure the stability of a protocol by the coefficient of variance (CoV). This stability metric is also used in [3]. In this metric, we take samples of transmission rates of the protocol flow being observed at a periodic timed interval. Each sample is the arithmetic average of the transmission rate observed during that interval. In our experiment, we are interested in the stability (or instability) that high-speed protocol flows induce to the entire network traffic. Thus, here we measure the total throughput observed at the bottleneck router instead of the transmission of a protocol. Below, we present the average CoV of the average values of the total throughput observed at the bottleneck router measured at every 10 second interval (we also have results for other time intervals; you can find more information from our experimental page linked below). We measure CoV after the first 200 second in each run of 1200 seconds.
Figure 12 shows the average CoV of the various protocol flows when two flows of a high-speed TCP variant run with the same RTT. No background traffic is added. In our experiment, 0.1 CoV indicates high instability. In this graph, we can see HTCP, STCP and TCP-SACK cause high fluctuations in the bottleneck router capacity usage. To demonstrate the level of instability with CoV 0.1 or higher, we plot the router capacity utilization of STCP and HTCP runs with 324ms RTT measured at every second interval in Figure 13. The total utilization of these two runs is around 80%. CUBIC, BIC and HSTCP achieve more than 90%. Information about the link utilization for this experiment can be found by clicking here.
Figure 12: Average CoV over 10 second interval. Two high-speed TCP variants running with the same RTT, no background traffic, 400Mbps. 2MB buffer. (More information)
(a) STCP (more information)
(b) HTCP (more information)
Figure 13: The utilization of STCP and HTCP flows measured at one second intervals. The light green line indicates the total utilization of the link capacity. 400Mbps, 324ms RTT, 2MB buffer.
Figure 14 shows the same metric of the runs with the same setup as the above but with background traffic. We observe that the CoVs of all the protocols have reduced. Thus, we can conclude that as we add more background traffic, the stability of protocols gets improved. But HTCP still shows very high CoV values. FAST also shows gradually increasing CoV values as RTT increases.
Figure 14: Average CoV over 10 second interval. The same environment as the above, but with background traffic. (More information)
Figure 15 shows the utilization measured at each second interval for various protocols after we add background traffic to the same experiment as in Figure 12. We observe that both STCP and HTCP have improved quite a bit compared to the no-background traffic case. FAST also fluctuates more with high RTTs and with background traffic. Although STCP has smaller time scale fluctuations than FAST, its CoV is less than that of FAST with 324ms RTT. This is because CoV (shown in Figure 19) is an average value over 10 second intervals implying STCP has much less fluctuations over a long-term scale than FAST with 324ms RTT.
(a) STCP (more information)
(b) HTCP (more information)
(c) CUBIC (more information)
(d) FAST (more information)
Figure 15: The utilization of HTCP, STCP, CUBIC and FAST flows of RTT 324ms measured at one second intervals after we add background traffic. STCP has improved substantially while HTCP still shows significant fluctuations.
This instability of HTCP does not happen only in long RTT networks, but also when different RTT high-speed flows are competing as we showed earlier. Figure 16 shows the average CoV when two flows of high-speed flows with different RTTs compete for the same bottleneck capacity (one is fixed to 162ms and the other is varied from 16ms to 162ms). This phenomenon is also observed in [2]. Unlike in the experiment with the same RTT in Figure 15, FAST shows much better stability. This indicates that the test cases must also include the cases with more diverse RTTs (even for the high speed TCP flows being observed).
Figure 16: Average CoV over 10 second interval. Two flows of the same TCP variant with different RTT (one flow with fixed RTT of 164ms, the other flow's RTT is varied from 16ms to 164ms). 2MB buffer with background traffic. (More information)
In the above we examined network capacity utilization and network stability. In this section, we examine packet loss observed at the bottleneck router as high-speed TCP flows compete for the bottleneck capacity. We measure the total packet loss at the bottleneck link and do not distinguish flows that experience packet losses. Like the stability measurement, this loss metric also measures the impact of high-speed TCP flows on the background traffic.
Figure 17: The packet loss ratio observed at the bottleneck queue. No background traffic, 2MB buffer. The losses include the total losses observed at the queue regardless of flows. (More information)
The packet loss ratio (the total number of packets lost over the total number of packets sent at the router) of various protocols is plotted in Figure 17. In this experiment, we do not add any background traffic and only two flows of the same TCP variant protocol with the same RTT run at the same time. We observe that HTCP has much higher loss rates than the other protocols in the runs with RTTs 80ms and longer. STCP also shows high packet loss rates as the RTT increases. This is because STCP is seeing the effect of small buffer sizes with high RTTs. FAST shows the least packet loss ratio among all the protocols.
As we add background traffic, we see packet loss rates for most protocols slightly increase. But STCP has a reduced loss rate with 324ms RTT. We conjecture that this is because the randomness present in the network improves the stability and robustness of STCP (and all protocols as well). Figure 18 shows the results. HTCP still induces significantly more packet losses even with background traffic than the other flows.
Figure 18: The packet loss ratio observed at the bottleneck queue. With background traffic, 2MB buffer. The losses include the total losses observed at the queue regardless of flows. (More information)
Figure 19 shows the packet loss ratio when two flows of the same TCP variant with different RTTs compete at a bottleneck link. Background traffic is added. The packet loss ratio of HTCP is among the highest. This behavior of HTCP is correlated with the CoV of HTCP shown earlier, implying high instability induces more packet losses (also utilization) in the network not necessarily only to its own flows but to the entire network flows.
Figure 19: The packet loss rate observed at the bottleneck queue. Two flows of the same TCP variant, but with different RTTs (one is fixed to 164ms and the other is varied). (More information)
We measure the fairness in sharing the bottleneck bandwidth among competing flows that have different RTTs. There are several notions of this "RTT fairness". One notion is to achieve the equal bandwidth sharing where the two competing flows may share the same bottleneck bandwidth even if they have different RTTs. This property may not be always desirable because long RTT flows tend to use more resources than short RTT flows since they are likely to travel through more routers over a longer path. Another notion is to have bandwidth shares inversely proportional to the RTT ratios. This proportional fairness makes more sense in terms of the overall end-to-end resource usage. Although there is no commonly accepted notion of RTT-fairness, it is clear that the bandwidth share ratio should be within some reasonable bound so that no flows are being starved because they travel a longer distance.
Note that RTT-fairness is highly correlated with the amount of randomness in packet losses (or in other words, the amount of loss synchronization) [1]. Under more random environments, protocols tend to have better RTT-fairness.
Figure 20 shows the RTT fairness of various protocols without any background traffic. Two flows are tested; we fix the RTT of one flow to 162ms and vary the other flow from 16ms to 162ms.
Figure 20: RTT-fairness tested with no background traffic (using Jain's fairness index). No background traffic. 400 Mbps. Two flows of each TCP variant are tested. One flow has a fixed RTT of 162ms while the other flow having a variable RTT from 16ms to 162ms. (More information)
FAST has the best fairness index. FAST achieves the equal RTT fairness among the two FAST flows regardless of their RTTs. CUBIC has RTT fairness linearly proportional to the inverse of the RTT ratio (i.e., the short RTT flow having proportionally more bandwidth share than the long RTT flow). So its RTT fairness is slightly lower than FAST. As we indicated above, we question whether this equal sharing property of FAST regardless of delays is desirable. HTCP and HSTCP seem to have similar RTT fairness. BIC's RTT fairness is lower than HSTCP but higher than STCP. This behavior is expected as explained in [1]. BIC is known to follow the same RTT fairness as TCP-SACK under a very large BDP network [1]. In the current testing environment, BIC's RTT fairness is targeted to be in between those of TCP and STCP. The argument is that in a network of this size, there will be enough multiplexing so RTT unfairness would not be so severe. We also found that HTCP allows the long RTT flow to have more bandwidth share. Figure 21 shows the bandwidth share and RTTs of the two flows of HTCP being tested. We found this quite unusual and do not know why HTCP has this behavior. We know that this behavior was not observed in the earlier version of HTCP.
(a) Bandwidth share of the two HTCP flows
(b) RTTs of the two flows
Figure 21: RTT fairness test of HTCP when one flow has 162ms RTT and the other flow has 22ms RTT (the delays shown in the figure include buffer delay as well). In these figures, we find that HTCP allows the longer delay flow to use more link capacity. (More information)
Figure 22 shows the same metric as in Figure 20 but with background traffic. In this experiment, we expect more asynchrony in packet losses. In the test, we found that background traffic has the biggest impact on FAST while in general, most protocols improve their fairness compared to the cases without background traffic. As suggested earlier, BIC's fairness has been improved substantially close to TCP-SACK as we add background traffic.
Figure 22: RTT fairness test with background traffic. In general, most protocols have gained in fairness with background traffic (for comparison, see Figure 20). CUBIC achieves a proportional RTT fairness (i.e., bandwidth share among the two flows are inverse-linearly proportional to the RTT ratio). FAST seems to have the biggest impact from the background traffic. (More information)
To see the behavior of FAST in more detail, we examine the transmission rates of the two competing flows of FAST in Figure 23 where one flow has 22ms RTT and the other flow has 162ms RTT. Without background traffic, FAST is able to achieve equal sharing. With background traffic, it does not. This is, we conjecture, because the second flow (red line) fails to estimate the minimum RTT of the link because of background traffic and thus fails to converge to the equal share.
(a) FAST with no background traffic
(b) FAST with background traffic
Figure 23: RTT fairness of FAST when two flows with different RTTs (one – 22ms and the other -164ms) compete. Without background traffic, FAST induces equal sharing while with background traffic, the long RTT flow fails to grab the bandwidth away from the short RTT flow.
We measure how TCP-friendly the high-speed protocols are by running experiments with one high-speed flow and one regular TCP flow with the same RTT over the same bottleneck link. These experiments were performed with and without background traffic. We measured TCP friendliness by Jain's fairness index [18] using the throughput of the high-speed flow and of the regular TCP flow. Jain's fairness index is a normalized number between 0 and 1 (1 being the greatest fairness). Jain's fairness indices for various high speed TCP variants are shown in Figure 24 as we vary the round-trip times from 16 to 324 milliseconds. The bottleneck bandwidth is set to 400Mbps. Figure 25 shows the results for 100Mbps link bandwidth.
Figure 24: TCP friendliness of various protocols with and without background under 400 Mbps. One regular TCP-SACK flow and one high-speed TCP variant flow, both with the same RTT, are running under 400Mbps link.
Figure 25: TCP friendliness of various protocols with and without background under 100 Mbps. One regular TCP-SACK flow and one high-speed TCP variant flow, both with the same RTT, are running under 100Mbps link.
From Figures 24 and 25, we observe that HTCP has the best TCP-friendliness in very low RTT networks (where TCP-friendliness is important because TCP-SACK does not have much performance problem) with or without background traffic. However, as RTT increases beyond 16ms, HTCP's fairness to TCP drops rapidly in both cases.
In general, we note that all TCP variants (except FAST) improved their TCP friendliness when background traffic is added to the experiments. This is mostly because of two reasons. First, increased background traffic takes away bandwidth from high speed TCP variants so they become less aggressive as their average window sizes become less than without background traffic. The other reason is that with background traffic, randomness in packet losses increases. As we can see that HSTCP (purple), CUBIC (red) and BIC (dark green) improve their TCP fairness indices considerably with background traffic, background traffic breaks loss synchronization and allows flows to adapt their transmission rates more asynchronously. In the same vein, this phenomenon occurs more vividly in a smaller bandwidth network as we can see in Figure 25-b (most notably with HSTCP).
We observe that FAST shows the best TCP friendliness in high RTT networks. This is not necessarily desirable because TCP-SACK is too conservative in high BDP networks. In addition, the TCP friendliness of FAST has been affected the most by the presence of background traffic.
(a) FAST and TCP without background traffic (Green is FAST, Red is TCP-SACK, and light green is the total utilization)
(b) FAST and TCP with background traffic (green - FAST, red - TCP-SACK, blue - long-lived TCP flows, purple - short-lived TCP flows)
Figure 26: Throughput of FAST and TCP-SACK with and without background traffic. 400Mbps, 82ms RTT.
A close examination of experimental results for FAST in Figure 26 shows that FAST (green line) is very friendly to TCP-SACK (red line) and consumes only the bandwidth left unused by TCP-SACK and the background traffic (blue line). It is interesting to note that FAST actually consumes less bandwidth than TCP-SACK in most of our experiments; FAST consumes more bandwidth than TCP-SACK only when the round-trip times increase above a certain value. Note that TCP-SACK becomes less effective in high RTT networks. These behaviors of FAST occur when FAST competes with heterogeneous flows that use packet losses as the only congestion indication. Loss-based protocols increase their transmission rates as long as there is no loss even when queuing delays are high. On the other hand, FAST will reduce its rate under such a circumstance. Thus, FAST becomes friendly to TCP flows, sometimes excessively so. More experimental results for FAST and TCP-SACK without background traffic can be found here, here, here, here, and here. Experimental results for FAST and TCP-SACK with background traffic can be found here, here, here, here, and here.
(a) STCP and TCP without background traffic (green - STCP, red - TCP-SACK, light green - total utilization)
(b) STCP and TCP with background traffic (green - STCP, red - TCP-SACK, blue - long-lived TCP flows, purple - short-lived TCP flows)
Figure 27: Throughput of STCP and TCP-SACK with and without background traffic. 400Mbps, 82ms RTT.
Experimental results for STCP (shown in Figure 27) indicate that STCP (dark green line) usually increases its congestion window too aggressively and causes the router queue to overflow frequently (these results are consistent with the observations that we made in Sections 1 and 6). This aggressive behavior of STCP causes TCP-SACK (red line) to reduce its transmission rate dramatically. When experiments were performed with background traffic, STCP still causes the router queue to overflow frequently but to a less extent than in the experiments performed without background traffic. In general, the throughput of the regular TCP-SACK flow only decreases slightly when background traffic is added. On the other hand, STCP obtains a considerably lower throughput in experiments with background traffic than without background traffic. This is the reason why STCP obtains a slightly better fairness index when background traffic is added (see Figure 24).
More experimental results for STCP and TCP-SACK without background traffic can be found here, here, here, here, and here. Details of experimental results for STCP and TCP-SACK with background traffic can be found here, here, here, here, and here.
Figure 28: Intra-protocol fairness of different protocols with and without background traffic. Two flows of a high speed TCP variant with the same RTT running over 400Mbps bottleneck link.
We measure the intra-protocol fairness of protocols by performing experiments with two flows of a high-speed protocol with the same RTT. The throughput of these two flows is used as input to compute Jain's fairness index. These experiments are conducted with and without background traffic and the round-trip times are varied between 16 and 324 milliseconds.
Without background traffic, HSTCP, TCP-SACK and STCP show lower fairness indices than the other protocols. However, as we add background traffic, we find that all the protocols (except FAST) show pretty good fairness. The reason for this result could be that since FAST is delay-based, background traffic introduced more dynamics and fluctuations in the bottleneck queue and made it more difficult for FAST flows to estimate their fair shares of bandwidth based on delay information. We also observe that HSTCP (violet line) obtained a higher fairness index in the presence of background traffic (as noted by its author, HSTCP relies on statistical multiplexing for faster convergence).
Figure 29: Throughput of two FAST flows with and without background traffic. 400Mbps. 82ms RTT
Figure 29 shows the throughput of two FAST flows (red and dark green lines) in experiments with and without background traffic. FAST shows very stable behavior without background traffic and the throughput values of the two flows are close enough without background traffic. However, as we add background traffic, we often find that one flow of FAST (green line) may dominate the other (red line) as shown in the figure. The contrasting behaviors of FAST with and without background traffic demonstrate again the importance of evaluating protocols in different scenarios, in particular evaluations with background traffic.
More information about experiments for FAST without background traffic can be found here, here, here, here, and here. More information about experiments for FAST with background traffic can be found here, here, here, here, and here.
Figure 30: Throughput of two STCP flows with and without background traffic. 400Mbps, 82ms RTT.
Figure 30 shows the throughput of two STCP flows (red and dark green lines) in experiments with and without background traffic. When the two STCP flows run without background traffic (Figure 30 (a)), they showed a great amount of unfairness (the throughput of one STCP flow was about three times as much as that of the other STCP flow). However, when the two STCP flows ran with background traffic, they achieved about the same throughput (see Figure 30 (b)). We also observe that background traffic helps the two STCP flows converge faster and better.
More information about experiments for STCP without background traffic can be found here, here, here, here, and here. More information about experiments for STCP with background traffic can be found here, here, here, here, and here.
Figure 31: Throughput of two HSTCP flows with and without background traffic. 400Mbps, 82ms RTT.
Figure 31 shows the throughput of two HSTCP flows (red and dark green lines) in experiments with and without background traffic. When the two HSTCP flows ran without background traffic (Figure 31 (a)), they showed a great amount of unfairness (the throughput of one HSTCP flow is about twice as much as that of the other HSTCP flow). However, when the two HSTCP flows ran with background traffic, they obtained approximately the same throughput. We also observe that background traffic helps the two HSTCP flows converge faster and better.
More information about experiments for HSTCP without background traffic can be found here, here, here, here, and here. More information about experiments for HSTCP with background traffic can be found here, here, here, here, and here.
Figure 32: Throughput of two HTCP flows with and without background traffic. 400Mbps, 82ms RTT.
Figure 32 shows the throughput of two HTCP flows (red and dark green lines) in experiments with and without background traffic. When the two HTCP flows ran without and with background traffic, each obtained approximately half the link capacity. It shows good fairness indices and convergence independent of background traffic.
More information about experiments for HTCP without background traffic can be found here, here, here, here, and here. More information about experiments for HTCP with background traffic can be found here, here, here, here, and here.
Figure 33: Throughput of two BIC flows with and without background traffic. 400Mbps, 82ms RTT.
More information about experiments for BIC without background traffic can be found here, here, here, here, and here. More information about experiments for BIC with background traffic can be found here, here, here, here, and here.
Figure 33 shows the throughput of two BIC flows (red and dark green lines) in experiments with and without background traffic. When the two BIC flows ran without background traffic, each flow obtained about the same throughput on average but they showed relatively slow convergence. However, when background traffic is added, the two BIC flows converge much faster. Each BIC flow still achieves approximately the same throughput when it runs with background traffic. The similar behavior is observed with CUBIC below.
Figure 34: Throughput of two CUBIC flows with and without background traffic. 400Mbps, 82ms RTT.
More information about experiments for CUBIC without background traffic can be found here, here, here, here, and here. More information about experiments for CUBIC with background traffic can be found here, here, here, here, and here.
Figure 35: Convergence time of different protocols with and without background traffic.
Figure 35 measures the convergence time of two high-speed protocol flows that are started at different times. The convergence time is defined to be the elapsed time when the timed average throughput of the second flow reaches 80% of the first flow (recall from section 2 that the two flows are started at 30 and 130 seconds). The average throughput is obtained at one second interval. The convergence time shown in Figure 40 allows us to discuss quantitatively the dynamic behaviors of protocols that we already qualitatively pointed out above.
CUBIC and BIC shows up to 150 second convergence time when running without background traffic. Under 300ms RTT, their convergence times reduce. This is because the small buffer size (of 2MB) allows the second flow to perturb the network significantly, when it goes into slow start, to force the first flow to drop its bandwidth share quickly. This case can be seen from STCP – because STCP is very aggressive, the second flow always forces the first flow to come down quickly. Thus STCP shows fairly short convergence times with high RTTs. (However, in most cases, STCP does not show good convergence beyond 80% with no background traffic) On the other hand, HSTCP shows very slow convergence time and also in most case, their convergence beyond 80% is not possible. As can be seen in Figure 35 (b), HSTCP (purple) reduces its convergence time considerably when running with background traffic. Further, STCP (yellowish green line) also showed improved convergence behavior with background traffic. On the other hand, FAST (brown line) increased their convergence time noticeably in the presence of background traffic. With low RTTs, FAST flows do not converge. The other protocols showed a rather short convergence time both with and without background traffic (note the change of scales of the y axis).
Figure 36: Fairness index of different protocols over different timescales.
While the convergence time sheds light on the dynamic behavior of the protocols, it does not necessarily give the complete view on the convergence behavior of the protocols. While the convergence time measures the time that the second high-speed flow takes until it reaches 80% throughput of the first flow, it does not provide any information about the dynamic behavior of these flows after that. Another metric that can be used to investigate the dynamic behavior of protocols is the average fairness index over different time scales.
In Figure 36, we show the average fairness index over different time scales of the protocols under evaluation when experiments were performed with a round-trip time of 82 milliseconds. We note that most protocols show equally good or better convergence behavior with background traffic. The only exception is FAST (brow line) that took more time to converge with background traffic than without background traffic. Another minor exception is BIC (red line) that shows slightly worse convergence behavior with background traffic.
In this rather long paper, we summarized the results of an evaluation study of a collection of congestion control algorithms for high-speed networks. We used various metrics such as fairness, convergence time, packet loss rates, link utilization, RTT fairness, TCP friendliness, and stability of throughput to evaluate these protocols. We focused on the impact of background traffic on the behaviors of these protocols. It is known that background traffic may affect the protocol behavior, but little is known "how" it is going to affect the behavior. Our study sheds a limited light to the problem. Further study will show more interesting properties with background traffic.
We do not declare any winner in our evaluation but simply show contrasting experimental results and complex protocol behaviors when experiments were conducted with and without background traffic. Our results demonstrated that different conclusions can be drawn when protocol evaluations were conducted with and without background traffic. Thus, evaluating a new protocol without background traffic can be dangerous and a thorough evaluation needs to look at a variety of testing scenarios to make a valid observation about the behavior of a protocol. Evaluations without background traffic may not give a full picture for the protocol performance (which is not new to know). While we do not claim that our models for traffic and propagation delays are the most realistic, we believe that the steps we took are at least steps toward the right evaluation of these protocols and hope that our work improves the methodology in evaluting various congestion control protocols.
Further, we also conclude that high-speed protocols have rather complex behaviors and a thorough evaluation of these protocols need to investigate all aspects of their behaviors. In light of our evaluation, it appears that there will probably be no "perfect" high-speed protocol that would be a clear winner in all different (and sometimes conflicting) aspects of protocol behaviors.
[1] Lisong Xu, Khaled Harfoush, and Injong Rhee, "Binary Increase Congestion Control for Fast Long-Distance Networks", INFOCOM 2004.
[2] Injong Rhee and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", PFLDnet 2005.
[3] Cheng Jin, David X. Wei and Steven H. Low, "FAST TCP: motivation, architecture, algorithms, performance", INFOCOM 2004.
[4] Sally Floyd, "HighSpeed TCP for Large Congestion Windows", IETF RFC 3649, December 2003.
[5] Douglas Leith and Robert Shorten, "H-TCP Protocol for High-Speed Long Distance Networks", PFLDnet 2004.
[6] Tom Kelly, "Scalable TCP: Improving Performance on Highspeed Wide Area Networks", Computer Communication Review, April 2003.
[7] Hadrien Bullot, R. Les Cottrell, and Richard Hughes-Jones, "Evaluation of Advanced TCP Stacks on Fast Long-Distance Production Networks", PFLDnet 2004.
[8] Yee-Ting Li, Douglas Leith, and Robert Shorten, "Experimental Evaluation of TCP Protocols for High-Speed Networks", Technial report, Hamilton Institute, 2005.
[9] C. Jin, D. X. Wei, S. H. Low, G. Buhrmaster, J. Bunn, D. H. Choe, R. L. A. Cottrell, J. C. Doyle, W. Feng, O. Martin, H. Newman, F. Paganini, S. Ravot, S. Singh, "FAST TCP: From Theory to Experiments", IEEE Network, January/February 2005.
[10] Ren Wang, Kenshin Yamada, M. Yahya Sanadidi, and Mario Gerla, "TCP with sender-side intelligence to handle dynamic, large, leaky pipes", IEEE Journal on Selected Areas in Communications, 23(2):235-248, 2005.
[11] Ryan King, Rudolf Riedi, Richard Baraniuk, "Evaluating and Improving TCP-Africa: an Adaptive and Fair Rapid Increase Rule for Scalable TCP", PFLDnet 2005.
[12] David X. Wei, Pei Cao, and Steven H. Low, "Time for a TCP Benchmark Suite?", Technical report, 08/2005, available at www.cs.caltech.edu/~weixl/research/technicals/benchmark/summary.ps .
[13] Sally Floyd, Metrics for the Evaluation of Congestion Control Mechanisms, August 2005, Internet draft, draft-irtf-tmrg-metrics-00.txt .
[14] Jay Aikat, Jasleen Kaur, F. Donelson Smith, and Kevin Jeffay, "Variability in TCP Roundtrip Times", ACM IMC 2003.
[15] Paul Barford and Mark Crovella, "Generating Representative Web Workloads for Network and Server Performance Evaluation", ACM SIGMETRICS 1998.
[16] G. Appenzeller, I. Keslassy, and N. Mckeown, "Sizing router buffers", in Proceeding of ACM SIGCOMM'04.
[17] Dhiman Barman, Georgios Smaragdakis and Ibrahim Matta, "The Effect of Router Buffer Size on HighSpeed TCP Performance", IEEE Globecom 2004.
[18] D. Chiu and R. Jain. "Analysis of the Increase/Decrease Algorithms for Congestion Avoidance in Computer Networks." Journal of Computer Networks and ISDN, 17(1):1–14, 1989.
[19] E. Altman, K. Avrachenkov, B.J. Prabhu, "Fairness in MIMD congestion control algorithms", in Proceedings of the IEEE INFOCOM, 2005.
[20] Sally Floyd and Vern Paxson, "Difficulties in Simulating the Internet", ACM/IEEE Transactions on Networking, Vol.9, No.4, pp. 392-403, August 2001.
[21] Luigi Rizzo, "Dummynet: A simple approach to the evaluation of network protocols", ACM Computer Communications Review, Vol. 27, No. 1, January 1997, pp. 31-41.
[22] Lixia Zhang, Scott Shenker, and David D. Clark, "Observations on the Dynamics of a Congestion Control Algorithm: the Effects of Two-Way Traffic", SIGCOMM 1991.
[23] Joel Sommers, Paul Barford, and Hyungsuk Kim, "Harpoon: A Flow-Level Traffic Generator for Router and Network Tests", extended abstract, ACM SIGMETRICS 2004.
[24] F. Hernández-Campos, F. D. Smith, and K. Jeffay, "Generating Realistic TCP Workloads", in Proceedings of CMG 2004, December 2004.
[25] Sally Floyd and Eddie Kohler, "Internet Research Needs Better Models", HotNets-I, October 2002.
[25] Sumitha Bhandarkar, Saurabh Jain and A. L. Narasimha Reddy, Kohler, " Improving TCP Performance in High Bandwidth High RTT Links Using Layered Congestion Control," PFLDNet 2005


text: Hi Guys Just found this useful little tool and thought any one who is into video blogging might find it saves them a few minutes work. It's not that revolutionary but a great way to get started making these sorts of blogs. Here is an example : www.yuckynastybugfacts.com Here is the FREE tool you can also use it for podcasting as well. http://www.blogmediauploader.com/

subset: commoncrawl


text:
Labor organizers are working to unionize call center employees in India. But as Miranda Kennedy reports, not all employees are eager to join.
Ted Koppel signs off today as the long-time anchor of "Nightline." Ashley Milne-Tyte reports on the likely fate of the late-night news show in light of declining viewership.
A new report out shows Wal-Mart often fails to charge an item's listed price at the checkout counter. Amy Scott reports.
New research excessive noise is bad for both hospital workers and patients. Helen Palmer reports.


text:
Beyond Social Media Show, Episode 52 Worst Cases Ogilvy Rips Off Web Comic Strip Author's Work Then Deletes It When He Calls Them Out On Twitter Twitter Wants To Know About Your Relationships Twitter Relationship Survey Worst Cases Multimedia Ogilvy Plagiarism They deleted their tweet, but here's the work @Ogilvy stole from me and claimed as their … [Read more...]
Posts about demographics from the eStrategy Content Marketing Blog archives.
Personas, Presentations & LinkedIn Publishing – Beyond Social Media #50 [VIDEO]
Beyond Social Media Show, Episode 50 Worst Cases Gwyneth Paltrow Compares Nasty Tweets To Suffering Through War Fresh Balls by Happy Junk Fresh Balls Sack Dance Video Marketing Personas: The Walking Dead Mary Meeker's State of the Internet, 2014 Presentation Redesigning Mary Meeker's Ugly Internet Slideshow Anonymous Animals in Google Drive … [Read more...]
Martha Stewart's Blogger Relations Blunder, Tide's Scary Vines & Twitter's Social Remote Control Button – Beyond Social Media Show [VIDEO]
Topics on episode 21 of the Beyond Social Media Show: Martha Stewart disses bloggers; boob sweat; poor PR pitches; Twitter opens the DM spam floodgates; Tide's scary Vines; Twitter & Comcast team to give you a social media remote control; Google buys gesture computing firm Flutter; Norton cleverly illustrates mobile privacy concerns; David Pogue bolts for Yahoo!; some shiny new … [Read more...]
Interview With VROU Co-Founder Kathryn Moos VROU, a new client, is a New York start-up that produces Water for Women, a convenient and effective way to get an excellent daily source of nutrients for women. CEO and Co-Founder, Kathryn Moos agreed to answer a few questions about VROU and what inspired her to start her own company. Kathryn Moos Q: What is your background and … [Read more...]
10 Most Popular e-Strategy Blog Posts Of 2012 [LIST]
These are the ten most popular posts this year at the e-Strategy Blog, based on the number of page views: How To Create & Market An Infographic TRANSCRIPTION FAIL: Speechpad vs. Dragon vs. Google Voice Citizens United Constitutional Amendment Online Ad Campaign Female Console Gamers The Kinect-Compatible Amazon.com Target's Falling For You Branded … [Read more...]
Target's Falling For You Branded Entertainment Campaign
Attitudes Toward Retail Product Videos 52% of online product video viewers are more confident in that product prior to purchasing it online 44% are more engaged with the retailer or brand as a result of watching their product videos 37% purchase more products on websites that feature product videos THOUGHT: Six years ago I wrote a piece called The End Of … [Read more...]


text:
What is the purpose of discount vouchers? Why do men and women obtain their favored stuff when merchants offer you reductions on costs? The logic is easy. Most men and women wait the total 12 months and acquire issues when they see massive vibrant sale banners on every single street. This is when they put their discount vouchers to the proper use. Most men and women like to do their purchasing in accordance to their comfort and ease degree. On the internet purchasing is a common choice in this relation. These cost reduction slips are offered for all item types. There is no point in spending massive quantity of funds when you can get all your favored stuff for less than 50 percent the cost.
Amazon.co.jp is listing a new PSP bundle. Packed with a PSP-3000, purchasers will get a obtain there are times when I for Last Fantasy VII Worldwide. Bundling one of the most significant RPG titles with a PSP is surefire way to promise some revenue. Neither Sony nor Sq. Enix have declared this to be an formal bundle, so as of now you can think about this one of Amazon's very own small packs. Both way, this is one difficult bundle for Japanese avid gamers to move up.
There was a whole lot of time talking about the laws, and online shoppers grew accustomed to the world wide web and not shell out revenue tax. As a end result, e-commerce firms began to increase exponentially. Regrettably, the keyboard cost-free ride is virtually more than. Several states have previously started to consider action and complain about the reduction of thousands and thousands of tax bucks in modern several years.
In truth, numerous paid out applications offer you 'lite' variations with decreased performance for cost-free. This implies that you can see if it's the app for you, ahead of you acquire.
With all of these Dorothy Perkins attire simplicity is crucial. There's a nicely-cut, easy design to match absolutely everyone, with no fussy information to detract from the flattering sort-fitting form.
Nowadays, world wide web purchasing is creating rapidly, it yields huge acceptance many thanks to promotional codes. They assist to improve revenue and meanwhile this functions enthusiastic on the shoppers. Sport voucher codes are created for greatest variety of video online games that can be obtained oline. New online games are introduced and accepted a lot more speedily to the market through these promotional codes and many thanks to them, they speedily achieve acceptance and get pleasure from unprecedented good results.
Patapon two functions several tiny tweaks to the profitable formula of the authentic in addition to incorporating new units for you to command. The sequel was unveiled on November 27, 2008 in Japan and March six, 2009 in Europe. North The usa will be the last major location to get Patapon two on May fifth.
There are so numerous legendary should-sees in New York that a weekend of sightseeing isn't practically ample. If that's all you have then why not consider in New York's popular landmarks all in one go, from the sky? A New York helicopter tour is an remarkable way to consider in New York's popular skyline, such as the town's tallest construction the Empire Point out Constructing, the Brooklyn Bridge and Lady Liberty herself.
A program – you considered you received absent with that one, didn't you. Plans, strategies, strategies; you do want them. Competition can be extremely intense in the voucher code market. You want to know just what you're allowing your self in for, the phrases you want to concentrate on and areas to get backlinks.


text:
Patrick Beall
Group President
Pat Beall serves as group president, with responsibility for agency operations and our mortgage service offerings. In this role, he oversees a diverse range of Stewart's business areas, including independent title agency network of Trusted Providers in the U.S.; technology sales for the agency network; Stewart Lender Services, and its offerings for loan originators, servicers and related providers; and Stewart Vacation Ownership.
Most recently, Beall served as executive vice president, senior director of agency operations. Previously, he was the south central states district manager for agency operations, with direct and indirect responsibility for Stewart's independent agency network in 22 states. His extensive experience includes title insurance, underwriting and real estate tax services.
A Stewart associate since 1986, Beall has also served as president of two affiliated entities, Professional Real Estate Tax Service and Baca Landata. He is a member of the Texas Land Title Association (TLTA) and its finance committee. He is also a former member of the Oklahoma Land Title Association's board of directors. He attended the University of Oklahoma in Norman.


text:
Last month, Artnet News National Art Critic Ben Davis came to Atlanta to be a mentor in BURNAWAY's Art Writers Mentorship Program [in which the interviewer is enrolled]. On March 23, he gave a well attended talk at Atlanta Contemporary [watch video here] that ended with a provocative Q&A session. We wanted to continue the conversation, hear about his Atlanta highlights (Lonnie Holley) and his thoughts on the Dana Schutz / Whitney Biennial controversy (it's complicated).
[The transcription has been edited and condensed.]
Carl Rojas: It's been about a month since you were here, so hopefully you've had a chance to reflect on your visit and develop some impressions.
Ben Davis: The conversation [at Atlanta Contemporary] was really exciting and people were engaged. I think sometimes that people outside of New York are more interested in the ideas around art than the people in New York. Money skews everything, like there's a whole other standard for who is up or who is down. Of course, BURNAWAY picked good artists for my studio visits, so I can't judge about Atlanta in general.
CR: What was the highlight of your visit to Atlanta?
BD: Easy. Meeting Lonnie Holley. Getting a view of the entire world around his show was interesting because it's wrapped in around his music. You step into a different world with that work.
CR: Shortly after your visit to Atlanta, you went to the press preview of the Whitney Biennial. Your piece in Artnet News was published before the public opening and the subsequent protests of Dana Schutz's painting of Emmett Till. Artnet News did a great job of covering that story, and Brian Boucher did a nice job of interviewing Schutz. I think she sounded a little sheepish in her words and in her public posture in response to the controversy. You didn't include the painting in your write-up, so I'm curious to know what your initial impression of that work was, and what are your thoughts about the controversy? Not to put you on the spot….
BD: You know, it's funny. I did an interview with the BBC and at the end they were like, "There's this little controversy in New York about the Whitney Biennial that's splitting the art world in two. Would you like to spend the last 10 minutes on that?"
CR: Where do you land between the two camps on the issue, one that says she has complete license to make the work and that she said the right things, and the other that she has no right to speak to the atrocity of what happened to Emmett Till, much less produce a painting about it?
BD: I've been trying to figure out if there is anything productive to be said about it. There's the whole dynamic of who gets to speak for whom, and does the great white male critic need to weigh in on this? It's just natural that it would just rub some people the wrong way. It occurred to me that people are working with different assumptions of what it means to be in the Biennial. If you look at the Biennial as a statement about American art and what it means to be an artist at this moment, you'd want people grappling with the political material of the time. But if you look at the Biennial as an art industry event that makes careers and generates status, and if you presume the art market is very corrupt, then you'd probably see it as making a product that capitalizes on that very sensitive image and an opportunity to sell posters. I think that art tends to be both ― where professional and creative collide. How you look at this material depends on which of these lenses you're looking through.
CR: I appreciate what you're saying. In the interview Brian did with her, I don't think she really addressed all of the concerns put forth by Hannah Black, and I think that's why this hasn't gone away.
BD: The thing is, I'm trying to figure out what I really think about the painting. Even the people I work with are divided. I believe that it was clearly intended as an anti-racist gesture. Honestly, I didn't even notice the painting when I was there for the press preview.
CR: You didn't notice it at all?
BD: No. Not at all. But we had another critic who was going to be addressing, specifically, all the painting in the show. So my piece was more about the overall Biennial. There's a lot of people piling on and saying that the artist and curators should've known better, but I think that's just a lot of ex post facto ― people wanting to place themselves on the right side of history. Henry Taylor's painting of Philando Castile's murder did stand out to me, maybe because I know his work less and it's a recent news image, so it leapt out at me. But no, I didn't notice Schutz's painting. There's a lot of sensitive material in that show.
CR: It's great that you gave a shoutout to Shara Hughes, who's from Atlanta, and the dreamy quality of her work. Her painting has improved so much since she left Atlanta.
BD: It is really beautiful work. The works that really registered with me were William Pope.L's work that is about counting Jewish people in New York and taking their pictures on slices of bologna. A fair number of Jewish artists and people came out and said that was offensive. I also found the Jordan Wolfson piece a little unsettling and disturbing.
You know going back to Schutz piece, I think you have to separate whether it's offensive from whether or not it deserves to be removed and destroyed. To the extent that it is offensive or bad, that's an act of art criticism and perhaps an indication that there is some well-deserved suspicion about the art market expressing political solidarity. It's as if just giving it a really bad review doesn't seem like enough. You have to feel like there's more.
Whether or not to take it down is a lot more complicated for me because, as a critic, I rely on free speech. I agree with Hannah Black that "free speech" is a little mythologized, so you don't yell "fire" in a crowded movie house. There are instances when free speech comes into conflict with the immediate demand for justice. You depend on free speech as a way to deal with attacks from the right wing, and the right wing is in power right now, so it's all very complex and hard to advocate for censorship. At this moment, I also feel like the right wing is feeding off this narrative of left-wing intolerance.
CR: I don't think Dana was trying to intentionally create this controversy. I'd like to think that had she known that this controversy would be the result of using that photo, she might not have done so.
BD: It is tough to navigate through this one. You are going to become a lightning rod by putting your opinion out there. You know, I find a lot of what well-meaning white people are saying as very problematic ― like if one person of color is offended by it, it should be destroyed. Black people aren't a monolith.
Kara Walker came out in support of Schutz. And she would because her work has also been the source of controversy. People thought she was being disrespectful with very sensitive material.
CR: I have an issue with some of Dana's responses where she tries to substantiate her thought process and make everybody feel that she was coming from the right place.
BD: This will be the big art story of the year.
Carl Rojas is an art lover who's married to BURNAWAY's Executive Editor.


text:
BIVEN Family Tree and BIVEN Genealogy Records
Last updated: 1970-01-01 | Researchers: 0 | Journals: 0
YES, I am a BIVEN researcher
Register yourself as a BIVEN researcher
Register yourself as a BIVEN researcher
This is the surname research page for BIVEN. This section is designed to contain general information about BIVEN genealogy research. Please consider adding some of your own research, either as an editor or with journals below.
What is this? This section (in blue) is available for editing to our advanced members, in a Wiki style. If you would like access to edit this surname page wiki, please contact us.
BIVEN Family History and BIVEN Family Genealogy Journals
Sort by: Newest | Alphabetical
There are no user journals for BIVEN. Be the first to contribute to this surname: Create a journal


text:
Ovela Venezia Quilt Cover Set (Queen)
Reminiscent of traditional Venetian gondoliers, this classic design will bring a peaceful style to any room, helping you drift off to sleep.
- Add black and white sophistication to your room
- Sink down into a bed of delicate, silky covers
- Stay cool in summer and warm in winter
Indulge in the best sleep of your life under the satisfyingly soft Ovela Venezia Quilt Cover Set. Made from 100% cotton, this 400TC quilt cover set is luxuriously soft to the touch.
The classic black and white stripes of this cover are timeless and versatile, enhancing the style of any room.
Cotton bedding improves your sleep
We all know just how crucial a good night's sleep is. With oh-so-soft, 100% pure cotton quilt covers to wrap yourself in, a deep, rejuvenating sleep will be yours to savour each and every night.
Pure cotton is ultra-breathable and works to absorb moisture away from your body while you sleep, helping you stay cool on those warm Summer nights.
Cotton is also naturally hypoallergenic – perfect for allergy sufferers – and a tighter weave ensures durability, meaning you can enjoy the simple indulgence of restful sleep for many years to come.
- 100% cotton
- 400 thread count
- Button closure on quilt cover
- 20cm insert in pillow cases
Due to health and safety regulations we are unable to accept this product for return under the terms of our Returns Policy for 'change of mind' purposes.
Returns for these products will only be accepted where the goods are deemed faulty under the terms of our Warranty Terms & Conditions .


text:
Celebrating ten years of Sebastian's Action Trust - a word from our CEO
With a robust calendar of celebratory events we knew that 2014 was going to be an exciting year for the Trust but we have been overwhelmed by an amazing initial six months. Ten years of providing emotional, practical and social support to families of seriously-ill and life-limited young people has been an enormous privilege; we are so proud to walk alongside our families from diagnosis, through treatment and beyond and our commitment to families remains steadfastly at the core of our operations. We know from some of the wonderful feedback we receive that our ever- evolving programme of services is much appreciated; for many we are considered a lifeline and a constant in lives that are frequently affected by unplanned change, worry and uncertainty. We remain focussed on listening to our families and responding with appropriate actions, helping where, when and how in order to meet the needs of whole families and individual members.
There have been many highlights over the past six months, too numerous to mention in their entirety, but here are a few of our favourites:
Outreach Services - Our service has expanded in 2014 with support from the Big Lottery, who have helped to fund some of our outreach team. Sue, Carla, Claire, Kelly and Peter, together with our Welfare Officer Jacquie now offer an outreach service to more than 200 families within the counties of Berkshire, Bucks, Surrey, Hampshire and Oxon. From listening to our families we have recognised the need to provide ongoing support beyond our family respite breaks at The Bluebells, so being able to extend our services to families whilst at home and in hospital has proven incredibly effective. We are pleased to announce that Katie will join us very shortly as our Youth Worker, with a Finance Worker to follow.
Blending our team with service user volunteers - We are delighted to see an increasing number of parents joining our team as volunteers. Tanya and Lyndsay are regular volunteers at The Bluebells, whilst Ben has become a befriender. Having our families intrinsically involved with the delivery of our service helps to keep us in touch with common issues, as well as being completely in keeping with our ethos that we are a "Family of Families".
Our Families have a collective voice - In March the Bluebells' Choir performed at the Mayor of Basingstoke's concert at Festival Place. Parents, grandparents, siblings, children and members of the Trust team faultlessly sang Gary Barlow's 'Sing' under the expert tutelage of parent Mark Halls and our Music Therapist Rebecca Pryce- there was not a dry eye in the house!
Our Garden of Reflection and Woodland Trail - Our amazing gardener Pam Duff continues to inspire and motivate countless volunteers to turn a stony, weed infested area into an incredible garden at the rear of The Bluebells. Our Corporates' Officer Jo King has networked with so many companies who choose to give their time, energy and services to create a wonderful new area which will enhance the magical qualities of a visit to The Bluebells.
Creating networking opportunities through The Bridge - Our Policy Officer Kathryn Griffith successfully organised our first foray into networking with the inaugural Bridge event, which brought together service users and service providers with the aim of connecting relevant parties and improving understanding of the issues affecting both sides.
A reception on the terrace at the House of Commons - Once again our good friend Sir George Young kindly supported the Trust by hosting a reception to highlight the achievements of our charity over the past decade. With many of our families having the opportunity to meet many MP's we were able to highlight some of the many issues that affect those caring for children with complex health needs.
Fundraiser of the Year! - Our Chief Development Officer Caroline Holton scooped the highly prestigious Gill Astarita's Fundraiser of the Year award at the 2014 Institute of Fundraising awards. We are very proud of her much deserved accolade and are delighted to see she is a leader in her field.
We are recipients of the charity MBE - We are so proud to have been awarded the Queen's Award for Voluntary Service. Recognising the commitment, passion and energy of our volunteers and staff, this achievement is a truly special endorsement of our cause and the people who make our charity such a unique organisation.
Over the past six months Sebastian's Action Trust has been at the forefront of delivering a much valued service to families coping with enormous challenges on a daily basis. As always, we recognise the need to continue to find new ways to address the difficulties that affect our families and we are proud of our reputation for being proactive, innovative and responsive to critical need. We look forward to an action packed second half of the year and are so grateful to our supporters for their continued commitment to our cause. Sebastian would be so proud of all that has been achieved in his name- here's to even more to come!


text:
The influenza virus (EIV)
Equine influenza is a major cause of respiratory disease in horse populations around the world. Current viruses belong to the subtype H3N8 and, like human influenza viruses, undergo antigenic drift due to the gradual accumulation of mutations in the surface glycoproteins. In particular, changes in the viral haemagglutinin (HA) help the virus avoid immunity acquired from previous infection or vaccination. As a result, vaccine strains need to be updated regularly. Current OIE recommendations are to include a representative strain from each of the two sublineages of EIV, Florida Clade 1 and Florida Clade 2.
|Cartoon showing influenza virus structure
Image kindly supplied by Dr Paul Digard
|Structure of influenza HA showing amino acid
differences between Florida clade 1 and
Florida clade 2 viruses
Working with


text:
Carpet tape and wide paper tape are the best options for securing a dance mat to the floor. The type of tape varies based on the flooring on which the mat is secured.
If you are attempting to keep your dance mat from sliding around on the carpet, carpet tape is suggested. Carpet tape is generally double-sided and made of fabric. It is found at many home improvement stores, such as Lowe's and Home Depot.
When securing a dance mat to a hard surface, such as tile or hardwood, it is best to secure the mat with wide paper tape. Using paper tape in place of duct tape is less caustic on the dance mat and is easier to remove when finished with the activity.


text:
For 12-year-old Jessica McElroy, writing the words was a breeze but saying them was another matter.
Jessica, a seventh-grader at Patuxent Valley Middle School, was one of the winners of "The Write Stuff," Howard County Public Library's poetry contest for youths. Winners and those receiving honorable mentions presented their original works during a reading Tuesday at Borders Books & Music in Columbia.
Jessica stood by shyly as judge Karen Arnold read her poem "Mask."
"I feel as though I don't belong, my life is told in one short song," Arnold read as one arm hugged the bashful scribe. "My world is down, deep and low, and every day I have nothing to show."


text:
Hewlett-Packard 9100A
The Hewlett-Packard 9100A (hp 9100A) is an early computer (or programmable calculator), first appearing in 1968. HP called it a desktop calculator because, as Bill Hewlett said, "If we had called it a computer, it would have been rejected by our customers' computer gurus because it didn't look like an IBM. We therefore decided to call it a calculator, and all such nonsense disappeared."[1]
The unit was descended from a prototype produced by engineer Thomas "Tom" E. Osborne, who joined the company when HP decided to adopt the project.[2][3][4]
An engineering triumph at the time, the logic circuit was produced without any integrated circuits, the assembly of the CPU having been entirely executed in discrete components. With CRT readout, magnetic card storage, and printer, the price was around $5,000 ($35,000 today).[5]
The 9100A was the first scientific calculator by the modern definition (i.e. trig, log/ln, and exponential functions), and was the beginning of Hewlett-Packard's long history of using Reverse Polish Notation (RPN) entry on their calculators.
Due to the similarities of the machines, Hewlett-Packard was ordered to pay about $900,000 in royalties to Olivetti after copying some of the solutions adopted in the Programma 101, like the magnetic card and the architecture.[6][7]
See also[edit]
- ^ a b "History of the 9100A desktop calculator, 1968". Hewlett Packard. Retrieved 2009-12-18.
- ^ "Osborne's Story". HP9825.com. Retrieved 2010-05-11.
- ^ "How the Model 9100A Was Developed", Bernard M. Oliver, September 1968, Hewlett-Packard Journal]
- ^ 1994 letter from Tom Osborne to Barney Oliver, hp9825.com
- ^ Federal Reserve Bank of Minneapolis Community Development Project. "Consumer Price Index (estimate) 1800–". Federal Reserve Bank of Minneapolis. Retrieved January 2, 2018.
- ^ "Olivetti Programma P101/P102". Old Computers. Retrieved 11 August 2010.
The P101, and particularly the magnetic card, was covered by a US patent (3,495,222, Perotto et al.) and this gave to Olivetti over $900.000 in royalties by HP alone, for the re-use of this technology in the HP9100 series.
- ^ Perotto, Pier Giorgio (February 10, 1970). "3,495,222 Program Controlled Electronic Computer" (multiple). United States Patent Office. et al. Google patents. Retrieved November 8, 2010.
External links[edit]
- "HP 9100A Calculator (marketing brochure)" (PDF). Hewlett Packard. 1968. Retrieved 2013-01-26. Hosted at the Computer History Museum.
- "HP 9100A/B". The Museum of HP Calculators. Retrieved 2013-01-26.
- Bell, C. Gordon; Newell, Allen (1971). "Chapter 20: The HP Model 9100A computing calculator". Computer Structures: Readings and Examples. McGraw-Hill. p. 243. ISBN 0-07-004357-4. Retrieved 2009-12-18.
- Steven Leibson interview of Tom Osborne
|This computer hardware article is a stub. You can help Wikipedia by expanding it.


text: My Droid has been working fine ever since I got it. I wake up this morning, check my e-mail, weather, etc. Then I make a call. During the call I try to use the number pad but it wont work. I can't hang up the call either. I pull the battery and reboot the phone thinking it was just a glitch with the phone.apk. After reboot the touchscreen still doesn't work. I tried a longer battery pull, about 10 minutes. Still the same thing. Then I tried restoring a backup from 6 days ago. Same problem persists. This really sucks. I'm guessing i'm going to have to flash the stock SBF and take it in to Verizon for warranty work (since its less than a year old) Anyone have any other ideas?


text:
The Techlog Drilling Performance Analysis training covers the basic theory governing the activity detection and interpretation of the Drilling Performance Analysis and Mechanical Specific Energy (MSE) computations.
Backed up with practical examples on actual datasets, the attendees will learn the fundamentals of Techlog itself: project structure and interface, family management, displaying data in both single and multi-well applications and a look at the real-time functionality. Following this, they will then be trained in the theory and usage behind the Drilling Performance Analysis workflow including the activity detection and breakdown, as well as interpretation techniques. Finally, an introduction and training on the MSE calculation and interpretation therewith.
Day 1
Project structure and managing data (create project, loading different format datasets, exporting data, depth data vs. time data, families management...)
Day 2
Displaying data (LogView, cross-plots, histograms)
Interaction tools
Real time functionalities
Drilling performance analysis introduction
Day 3
Drilling performance analysis practicals
mechanical specific energy workflow and practicals
Drilling engineers.
Basic understanding of drilling and geology.


text:
A late scoring change wound up changing the team champion at the Country Club Swimming League meet July 14 at Ohio State.
A late scoring change wound up changing the team champion at the Country Club Swimming League meet July 14 at Ohio State.
Originally, Scioto was awarded the team championship trophy with 2,573 points, with Wedgewood second with 2,570. Adjusted, Wedgewood won with 2,574 and Scioto was second with 2,569. The rest of the results -- The Lakes (2,312), New Albany (1,734), Worthington Hills (1,488), Tartan Fields (1,359), Brookside (1,268), Muirfield (990.5), Kinsale (855.5), Medallion (844), Jefferson (766.5), Columbus (138.5) -- stayed the same.
The discrepancy, discovered 45 minutes after the trophy presentation and after most in attendance had left, happened in the boys 11-12 50-meter freestyle. Wedgewood's Ryan McLoughlin was an alternate for the event but got to swim when an athlete from Scioto did not show up. McLoughlin finished 17th and earned four points, which in error were awarded to Scioto.
Once the mistake was discovered, team results were changed accordingly.
ThisWeek, which had a reporter on site throughout the meet and for 30 minutes after the completion of the awards ceremony, was not notified of the change until nine days later.


text:
In January, every road game counts. It's the home stretch. Kevin Durant loves playing on the road, where it's his team against the world. The newest colorway of the KD7 puts a twist on a traditional away shoe with a unique camo- and lightning-inspired graphic on the Hyperposite heel.
If a size is not listed, it is sold out.
Nike KD VIILight Blue Lacquer/Clearwater-Total Orange-White653996-414


text:
Subscribe to our Newsroom RSS feed | What is RSS?
Follow Loyola University New Orleans on Twitter
Professor of Religious Studies delivers Yamauchi lecture March 21
Loyola press release - February 19, 2004
Loyola Professor of Religious Studies Grant Kaplan, will deliver the spring Yamauchi lecture Sunday, March 21, 2004 at 7:30 p.m. in Nunemaker Auditorium in Monroe Hall. The lecture titled Can Doctrine Develop? Reflections on the German Contribution is free and open to the public.
Kaplan is assistant professor of systematic theology. He received his doctorate degree in 2003 from Boston College. A Fulbright Fellowship enabled him to study in Tubingen and a dissertation fellowship brought him to the University of Fribourg, Switzerland. His dissertation "Answering the Enlightenment? Friedrich Schelling, the Catholic Tubingen School and the Recovery of Historical Revelation," treats the question of revelation for Catholic theology in light of the problematic situation that arose in the Enlightenment. He has published several translations from German writers on theology and feminist anthropology.
The Yamauchi Lectures in Religion series was begun in 1985 in memory of the Rev. H. James Yamauchi, S.J., former chair of the Department of Religious Studies who taught at Loyola University New Orleans from 1956 to 1966. Yamauchi was known for his effective communication of knowledge about religion to the New Orleans community, and this lecture series seeks to perpetuate his work by bringing the results of religious scholarship to a wider audience.
For more information, contact the Department of Religious Studies at 865-3943.


text:
Australian wagering and lottery operator Tatts Group has sold its UK-facing slots division Talarius to the UK division of Austria's Novomatic Group.
On Monday, Tatts announced that Novomatic UK had agreed to buy Talarius, which operates Quicksilver-branded slots venues. Tatts said it expects to realize a net gain of £111m from the transaction. The deal gives Novomatic the economic benefit of the Talarius business as of March 19, 2016.
Talarius' contribution to Tatts fiscal 2015 earnings was a mere A$6.2m, less than 2% of total earnings, and Tatts says the sale won't have a material impact on its continuing earnings per share. Tatts said the divestment will result in a non-cash accounting loss of A$50m in the company's fiscal 2016 numbers.
Tatts acquired Talarius back in 2008 and Tatts CEO Robbie Cooke says the company made an "intense effort" over the last three years "to improve the performance" of the slots business. Now that it has become "a very attractive asset in a highly competitive gaming segment," the time was right to sell.
The sale reduces Tatts' gaming unit to the Maxgaming electronic gaming services division and the Bytecraft technical support services business, meaning Tatts' gaming unit no longer has a B2C component.
Tatts also offered the markets a trading update on its FY16 numbers for the 11 months up to May 31. Overall growth in Tatts' mainstay lottery operations was up 8.7% over the same period last year, while wagering turnover rose 4.2%.
In keeping with recent trends, Tatts' online operations reported the most significant growth, with online lottery sales up one-third, representing 13.5% of all sales. Similarly, online wagering was up nearly 23%, representing 30% of sales.
When the final FY16 numbers are released on August 18, Tatts expects net profit after tax to come in between $255m to $265m, excluding the Talarius contributions.


text:
The right time to prune peach trees is when the buds begin to bloom just enough to see the pink flower emerge from the tip. When pruning, it's important to remove old gray shoots and keep year-old shoots that are redder in appearance.
Peach trees should not be trimmed when they are dormant as they are weak in cold weather and more susceptible to dieback during that time. Dieback causes a plant to die from the branch tips back in towards the roots and can be brought on by the environment, bacteria, fungi or viruses. To avoid dieback, it is better err on the side of caution and trim a bit late, as opposed to too early. Peaches grow on 1-year-old branches, so annual heavy pruning generates new fruit-producing branches each year.
To prevent shade on lower blossoms and maximize sun exposure, choose three to five main branches of the peach tree, and prune them to move upward and outward from the trunk at a 45-degree angle. Damaged, diseased and broken branches must also be pruned to reduce congestion and ensure healthy new growth. Aim to keep branches that are shorter than 18 inches and as thick as a pencil. Control the height of the tree and allow for an easier harvest by topping off branches to an accessible height.


text:
- This event has passed.
CWRA Saskatchewan Branch 2017-18 Webinar Series: Smith Project Naturalization/Decommissioning
May 9 - July 9varies
The Saskatchewan Branch of the Canadian Water Resources Association invites you to take part in our upcoming webinar series. We have confirmed a set of impressive speakers on a number of interesting topics related to water resources and management in Saskatchewan (visit website).
Catch the whole series for the package price of $35 for CWRA Members, $20 for Students, of $70 for Non‐members.
Or register for individual webinars for $10 each for CWRA Members and $15 each for Non‐members.
Please note, registration is required at least 3 days in advance of the webinar to allow for the webinar link to be provided. The webinar link will be provided by email a day or two in advance of each webinar.


text:
Workers Compensation Insurance
At TW Group, Inc., we know that having a workplace that is protected, gives you the extra security you need for your business— in case one of your employees is injured.
As an employer, you have an obligation to ensure a safe work place and the law requires a business to have Workers Compensation Insurance. Work Comp insurance can provide the coverage to protect you from those unpredictable occurrences.
TW Group, Inc. can offer many different programs for different industries, and develop a customized a package that fits your needs and industry. We take a proactive approach to our clients' Workers Compensation challenges. We will work to reduce your insurance costs, thereby saving you money this year and years to come.
Coverage and benefits can be obtained for the worker no matter who is at fault. For those workers injured in the workplace, medical expenses and income replacement may be necessary. Our network of companies and experienced agents can analyze your work comp insurance needs. By contacting us today, we can assist and guide you through these complicated steps.
How does this benefit the Illinois business owner?
- Reduced injuries and losses
- Reduced medical and disability costs
- Reduced policy adjustments
- Reduced premium costs
- Servicing your work comp insurance needs
Having the proper Illinois workers compensation coverage can protect your employees and your business from loss and financial damage.
Try our online quick quote forms now, or call us at 630-737-0300.


text:
100 NE First StreetGainesville, FL 32601Phone: (352) firstname.lastname@example.com here for directions
Eucharistic Ministers are parishioners who are trained by the clergy and licensed by the Bishop to assist at the Eucharist by leading the Prayers of the People and administering the chalice.
At Holy Trinity, Eucharistic Ministers are known as calicifers—a descriptive word for "chalice bearer" coined by a late parishioner.
for more information on Calicifers, please contact email@example.com


text:
(The Spread) – Week 1 of the 2012 CFL Regular Season kcks off tonight with two matchups. Let's check out the odds.
At 7:05PM ET the Hamilton Tiger-Cats will host the Saskatchewan Roughriders in Hamilton, Ontario, Canada. The Tiger-Cats opened as a 7-point favorite while the over/under is currently sitting at 50.5 points.
Hamilton finished the 2011 season with an 8-10 record, which placed the Tiger-Cats third in the East Division. The Roughriders slumped to a 5-13 finish and wound up in dead last in the West.
In its two preseason games this year, Saskatchewan was routed 44-10 by B.C. and then lost 33-31 to Calgary. Hamilton, meanwhile, lost 29-24 to Toronto before beating Winnipeg, 26-25. The two teams split their regular season meetings last year, with the Tiger-Cats crushing the Roughriders 33-3 in the first matchup and Saskatchewan returning the favor with a 19-3 victory against Hamilton in the second meeting.
View Real-Time Sports Betting Odds
The second game tonight features the defending Grey Cup champion B.C. Lions hosting the Winnipeg Blue Bombers, the team the Lions beat in the championship last November. After B.C. thumped Winnipeg 34-23 in the Grey Cup last season, the Lions have opened as a 7.5-point favorite in the 9:05PM ET game tonight. The over/under total for this game is 51.
The Lions lost their first five games last year before rattling off 11 wins in their final 13 games to win the West Division. The Blue Bombers, meanwhile, finished 10-8 and won the East Division, but they proved to be no match for B.C. in the Grey Cup. That said, Winnipeg did beat B.C. in the teams' only two regular season meetings of 2011.
Want More From TheSpread.com? Follow us on Twitter and Facebook or Subscribe to Our News Feeds!