Analysis of TCP’s Computational Energy Cost for Mobile Computing
Bokyung Wang and Suresh Singh
Department of Computer Science
Portland State University
Portland,OR97207
Accepted to ACM SIGMETRICS2003as a Poster
Full paper submitted for publication to J.Wireless Networks
Abstract
In this paper we present results from a detailed measurement study of TCP(Transmission Control Protocol)running over a wireless link.Our primary goal was on obtaining a breakdown of the computational energy cost of TCP at the sender and receiver(excluding radio energy costs)as a?rst step in developing techniques to reduce this cost in actual systems.We analyzed the energy consumption of TCP in FreeBSD4.2and FreeBSD5running on a wireless laptop and Linux2.4.7running on a wireless HP iPAQ3630PocketPC.Our initial results showed that60-70%of the energy cost (for transmission or reception)is accounted for by the Kernel–NIC(Network Interface Card)copy operation.Of the remainder,15%is accounted for in the copy operation from user space to kernel space with the remaining15%being accounted for by TCP processing costs.We then further analyzed the TCP processing cost and determined the cost of computing checksums accounts for20–30%of TCP processing cost.Finally,we determined the processing costs of two primary TCP functions–timeouts and triple duplicate ACKs.Putting all these costs together,we present techniques whereby energy savings of between20%–30%in the computational cost of TCP can be acheived.
1Introduction
Communication underlies many applications run by users of mobile devices and thus there is a need to better understand how and where energy is consumed in the communications pipeline.Prior work by various researchers(discussed in section2)has looked at the energy consumption of various wireless interface cards[12,13],the impact of ARQ(Automatic Repeat reQuest)protocols on overall energy consumption,the effect of channel conditions on energy consumption,and comparative energy and throughpout-based studies of different TCP?avors.While all of these studies have contributed a great deal to understanding the impact of the wireless link on the overall end-to-end energy consumption,none of these studies has looked at the computational energy cost of running the TCP protocol itself.In this paper we analyze the computational energy cost of the TCP protocol in detail and use this analysis to develop approaches by which the node-level cost of running TCP can be reduced.Interestingly,our results show we that approaches for optimizing TCP for high-speed network operation,can,in some cases,result in lower energy consumption in the wireless domain as well!
The computational cost of TCP includes the cost of various copy operations,the cost of computing checksums,the cost of responding to timeouts and triple duplicate ACKs,and other bookeeping costs.Our goal in this study is to estimate the energy(in Joules)taken by each of these operations,and,in order to ensure that our results are robust,we performed these measurements on three different systems.The bene?t of our study is fourfold:?rst,it enables us to develop techniques to reduce the computational energy cost of TCP;second,other researchers working on developing throughput models for TCP can use the results of our study to simultaneously develop energy models since we have characterized the cost of the primary TCP functions;third,our node-level energy models can be incorporated into simulators such as NS-2[1]to obtain overall energy cost of TCP connections(NS-2currently only includes the radio energy cost);?nally,the methodology we have developed can be used by others to evaluate the TCP energy cost in their system of choice.
The remainder of the paper is organized as follows.In the next section we discuss related work;section3presents an overview of TCP processing and describes the key tasks that are energy consuming;section4details the methodology we followed in our study to estimate the various energy costs;results of our measurement are described in section5;we
1
use the results of our measurements to develop techniques to reduce the overall computational energy cost of TCP and a discussion of this is presented in section6;?nally,section7presents our conclusions.
2Related Work
The TCP protocol has been analyzed in the past decade by a large number of researchers for a variety of different reasons. Of this large body of prior work,however,we focus on two speci?c sub-areas that are directly relevant to the work reported in this paper:work that has analyzed the energy consumption of TCP(or other protocols)for wireless networks and work that has examined the performance of TCP at the node level(where the goal was to enable end-systems to operate at gigabit speeds).While our paper focuses on the wireless domain,we see that many of our results are parallel to those obtained for making TCP operate at high data rates.
[8]is one of the earliest papers that examined the processing overhead of TCP.The goal of this work was to see if TCP processing was indeed a bottleneck in end-to-end connection throughput.The authors counted the number of instructions executed in TCP and IP at the sender as well as at the receiver when TCP follows the“normal path”of execution.In addition to instruction counts,they also provided a breakdown of the processing cost in terms of time consumed.We refer to speci?c results of[8]later in our paper(sections5.2and5.3)where we draw comparisons with out own measurements. Among the results of[8]is the conclusion that TCP processing cost is not high,contrary to popular belief in1989,and is not the bottleneck to achieving high data rates.
In order to get TCP to operate at gigabit speeds,researchers have developed methods in software as well as in hardware. We do not provide a comprehensive discussion of the various results here because our focus in this paper is on wireless networks.However,it is useful to list some of the main techniques developed because our results indicate that some of these techniques developed for high-speed TCP can also result in energy savings in the wireless domain where TCP processing speed is not as important!The techniques developed by the high-speed TCP community(for example[21,5, 22,3,17,15,10,9,7])include,on the software side,using zero-copy,header prediction,interrupt supression(where the processor is only interrupted when several packets have been received),using jumbo frames,and integrating checksum computation with copy.In hardware,the techniques suggested include,checksum of?oading,of?oading some common path TCP/IP functionality to the NIC(Network Interface Card),packet aggregation on the NIC card,etc.The goal of all these optimizations is to ensure that applications can run at network speeds and not be hampered by TCP’s processing.
In the wireless domain,there have been several papers dealing with the problem of TCP’s energy consumption over wireless links where energy consumption is modeled as the ratio of the number of successful transmissions to the total number of transmissions.Most of these papers focus on the impact of the link layer on the energy ef?ciency of TCP.
[29]considers the effect of ARQ strategies on energy consumption.The key idea is to suspend packet transmission when channel conditions worsen and probing the channel state prior to packet transmission.When channel conditions improve, packet transmission is resumed.[30]analyzes the energy consumption performance of various versions of TCP for bulk data transfer in an environment where channel errors are correlated.The paper only considers one-hop wireless links with zero propagation delays.[19]also considers the effect of ARQ,FEC(Forward Error Correction)and a combination of the two on energy consumed in ad hoc networks.The paper uses the Maisie simulation language and Glomosim to perform the study.The underlying theme in these papers is that reducing the number of unnecessary retransmissions implies better energy ef?ciency.
In the recent past there have been simulation-based studies[31,11]of throughput and energy consumption of TCP connections in wireless networks.These studies investigate the tradeoff of radio transmit power on the throughput of TCP.[31]concludes that increased trasmitted power(RF power)is not always good as their study shows that increased transmitted power results in higher TCP throughput up to a point(because of better signal to interference ratio),after which an increment of transmitted power actually leads to worse performance due to greater interference.[11]examines the effect of transmission range on the energy as well as throughput of TCP in multi-hop networks.They model energy as a sum of the idle energy consumed for the duration of the connection and the sum of the hop-by-hop transmit energy consumed (path loss is the primary contributor to this energy cost).The throughput is modeled as being inversely proportional to the product of the packet error rate and the square root of the round trip time.The authors then show that decreasing the transmission range will result in lower overall energy consumed but will decrease throughput.However,decreasing the transmit energy beyond a certain point will result in an increase in energy because the throughput falls to very low levels and the idle energy cost dominates.While interesting,this paper appears to make several simplistic assumptions about the radio environment,such as:ignoring the relationship between packet loss rates and decreased transmit power,
2
energy consumed by receiver nodes(since each transmission is often heard by several neighbors),and the possibility of radios entering sleep states to minimize idle power consumption.[27]compares the energy and throughput-ef?ciency of TCP error control strategies for three implementations of TCP Tahoe,Reno,and New Reno.They implemented the three versions of TCP using the x-kernel protocol framework and their focus was to study heterogenous wired/wireless environments.Finally,[26]provides an energy and throughput comparison of TCP reno,newreno,and SACK for multihop wireless networks.This paper reports on the results of actual energy measurements and the primary conclusion is that TCP newreno work best in wireless environments.
Unlike the papers discussed above,the focus of our work has been on examining the computational energy cost of TCP. This cost is affected by the software as well as by the hardware of the mobile node.We explore this relationship in detail and then develop approaches that would result in a reduction of the node-level TCP energy cost.Our work can thus be thought of as complimentary to the above referenced wireless papers in that while we look at the node-level cost of running TCP,the other papers examine the impact of the propagation environment on the total end-to-end cost of TCP.
3Energy consumption in TCP
The computational energy cost of a TCP session established by a wireless device can be viewed as the total energy cost of the session minus the cost of the radio and the idle energy cost of the connection(i.e.,when the node is idle awaiting ACKs or data segments).Consider the example illustrated in Figure1which provides plots of current draw versus time. The upper curve is the total system current draw for a laptop equipped with a802.11b radio card and the bottom plot is the simultaneous current draw for the802.11b card alone.In this plot,the laptop is acting as a sender for a ttcp[28]connection. In order to determine the computational energy cost of this connection,we?rst delete all portions of the system current plot in which the system is idle(this corresponds to the areas in the upper plot marked by A–not all areas are marked for clarity).We are then left with a plot consisting only of those periods that show TCP related activity(i.e.,the regions marked C).From these activity periods we subtract out the radio energy cost(the regions in the lower plot marked as B). This?nal data is summed over the lifetime of the connection(the units are Ampere-second)and multiplied with the voltage to give us the total computational energy cost of the connection(we provide an example of this calculation in section4.2). Thus,we see that this procedure appropriately eliminates the radio cost(transmit/receive/idle/sleep)and the idle system cost from the measurement.The energy value obtained is thus the pure hardware/software cost of running TCP at the node.
Our goal in this paper is to decompose this computational energy cost further so as to better understand which TCP/IP
3
functions cost more energy.To this end,we view the TCP computational energy cost as being composed of the following primary components:
The cost of moving data from the user space into kernel space that we denote user-to-kernel copy.Note that this cost can be eliminated by using zero-copy[24,6],if available.
The cost of copying packets to the network interface card that we denote as kernel-to-NIC copy.
The cost of processing in the TCP/IP protocol stack(TCP Processing Cost)which includes:
–The cost of computing the checksum(at sender and receiver),
–The cost of ACKs(at sender and receiver),
–The cost of responding to timeout events(TO)(at the sender this is the processing cost plus NIC-to-kernel copy
cost of the retransmitted packet),
–The cost of responding to triple duplicate ACKs(TD)(at the sender this is the processing cost plus the NIC-to-
kernel copy cost of the retransmitted packet),and
–Other processing costs such as window maintenance(at sender on receiving ACKs),estimate round trip time
(at sender),obtaining the TCB(Transmission Control Block),interrupt handling,and timer maintenance12 While it is possible to break down some of these costs even further,we believe that this level of granularity is suf?cient for most modeling https://www.doczj.com/doc/4216320847.html,ing this breakdown,the total computational cost of a TCP session,in which bytes of data are transmitted,can be written as:
MTU Size user-to-kernel copy for bytes checksum cost for MTU packets
ACK cost kernel–NIC copy cost for MTU
(1)
packets of size MTU Number of TOs TO copy and processing cost
Number of TDs TD copy and processing cost Other processing costs
We have written the total energy cost as a function of the MTU(Maximum Transmission Unit)size because different MTU sizes result in different total energy costs.
4Methodology
4.1Experimental Setup
In order to ensure that our measurements of TCP’s computational energy cost are widely applicable,we performed the measurements on three different platforms:
Toshiba Satellite2805-S201laptop with a650MHz P3Celeron processor,256MB RAM running FreeBSD4.2, The same laptop running FreeBSD5.0,and
A Compaq iPAQ H3630PocketPC with a StrongARM processor running Linux2.4.7.
The same network card was used for each of the three platforms above–a2.4GHz Lucent802.11b WaveLAN“Silver”card.Finally,power management was turned off in the computers as well as the802.11card for our experiments.The display was also off and the x-server was not running.
Energy consumption was determined by measuring the input voltage and current draw using two Agilent34401A digital multimeters that have a resoultion of one millisecond.We did not use batteries in the devices because,as noted in 1In this paper we chose not to analyze TCP options such as SACK(Selective ACK)but rather concentrate on the core TCP implementation alone.
2We have not isolated the cost of interrupt processing but rather folded it into the various processing costs.
3Typical TCP modeling studies(see[20,25])proceed by obtaining the probability of TD and TO events as a function of packet loss rates and then using these values to obtain throughput as a function of packet loss probability,round trip time,window size,etc.The primary factor affecting throughput is the presence of TO and TD events since these result in a reduction in the congestion window size.Given this,we believe that the level of granularity we use to characterize energy consumption is adequate for modeling purposes.
4
[13],avoiding the use of batteries allows for a more steady voltage to be supplied to the device.Since our goal was to measure the computational cost of TCP alone,we needed to separately but simultaneously measure the current draw of the laptop/iPAQ and the current draw of the802.11b PCMCIA card(as illustrated in Figure1).To do this,we followed the methodology described in[13,12,26]in which,the802.11b PCMCIA card is attached to a Sycard PCCextend140A CardBus Extender[16]that in turn attaches to the PCMCIA slot in the laptop or iPAQ.This extender is a breakout box which allows us to directly measure the current and voltage draw of the802.11b card.Our?nal experimental set up was as follows:the laptop’s(or iPAQ’s)power supply is measured by one Agilent34401A multimeter while the802.11b’s power supply is measured by attaching a second Agilent34401A multimeter to the appropriate terminals on the Sycard CardBus extender.Both these multimeters are triggered simultaneously by a second laptop that also collects data from these multimeters.The average current and voltage measurements are given below:
Measured Average Current(mA)V oltage
Transmit Receive Idle(V/DC)
Toshiba Laptop19051709122015.08
HP iPAQ655630517 5.05
WaveLAN263181159 5.046
4.2Sample Measurement
In order to measure the computational energy alone,we need to identify and then subtract out the energy consumed by the radio as well as the idle energy consumed by the laptop/iPAQ.We illustrate this process via the example shown in Figure 2.In this?gure we plot the measured simultaneous current draw for the laptop and the WaveLAN card(MTU1500bytes). We make the following observations:
The radio continues transmitting long after the packets have been copied to its input buffer(the TCP processing and copy operation corresponds to the region between A–B and C–D in the?gure).This is because the packets are copied at a much higher speed of20MBytes/sec over the PCMCIA bus as compared with the radio transmission speed.
Interestingly,we see that the radio transmission speed is far below speci?cations and is approximately1.2Mbits/sec (see also Figure5).
The computational energy cost of TCP is calculated as follows:
For all measurements of system current draw above idle,we compute the total current drawn assuming that the current draw is constant over1msec intervals(we needed to do this becasue the resolution of our multimeter is1 msec).In Figure2,this means that we sum the current in regions A–B and C–D.For the sake of illustration,let us only consider region A–B.The sum of the current draw here is17137.6Ampere-Second.The energy draw is therefore0.258Joules(after multiplying with the voltage drawn).
We next compute the radio energy drawn for this same period.In our example,the radio energy drawn in the period A–B is0.012Joules(note that the radio card runs at5V rather than15V).
The computational energy cost is then the difference of the above two values.In our example,this gives us a value of0.246Joules.Our experiments used a send buffer size of16KBytes or approximately11packets.Thus,the per packet computational energy in this example is0.022Joules(see Figure4where we plot the packet cost).
Note that by following the above procedure we discount the idle energy draw of the system as well as the radio cost.In order to compute the computational energy as described above,we wrote scripts that automatically performed the above algorithm on very large data sets.
4.3Parameter Selection
We used ttcp(the buffer size for ttcp was set at8192bytes)to measure the energy consumption for transmitting1MByte of data.We simultaneously ran tcptrace[18]and tcpdump[28].The information collected from these tools was used to identify the radio events(B in Figure1)and appropriately subtract the corresponding radio energy cost from the overall system cost(C in Figure1).The parameters we used for the various measurement experiments are illustrated below.
5
Paramaters Values
TCP window size16K
RTS/CTS OFF
MTU Size168,296,552,960,1500bytes
Packet Loss No default setting(for most experiments)
3%,5%,7%,10%using Dummynet(for experiments in section5.3 In order to determine the energy consumed by various functions of TCP,we needed to set up TCP connections from our test devices via a wireless LAN to some host.We used an access point that was connected to the local100Mbps ethernet backbone.For some studies(such as those where we studied the cost of TD and TO processing)we needed to carefully control the packet loss rates.To do this,we ran Dummynet[23]at a local node in the connection path and dropped packets from the ttcp connection.
5Results&Analysis
We have divided the measurement results into three sections for reasons of clarity:
In the?rst section we discuss the total computational and radio energy costs and provide a comparison between the three systems.The radio energy costs include the transmission and reception costs only(i.e.,we discount the idle radio energy cost because,as noted in[27],in the case of low throughput the idle cost would dominate all others).
In sections5.2and5.3we provide a breakdown of the total computational energy cost into the major components discussed in section3.
Finally,in section5.4we validate our results in a new set of experiments in which we compare predicted energy cost and the actual energy measured for these connections.
We would like to note that for all the plotted data in the following sections we show95%con?dence intervals that were obtained by combining data from between50and100repetitions of each experiment.
6
5.1Comparison of computational energy costs between the three systems
In this?rst set of experiments,we set up TCP connections with a local host and the three systems were placed in the exact same physical location in the laboratory and were close to the access point45.One megabyte of data was sent from or to each system using ttcp.The?rst study compares the computational energy cost of the three systems(acting either as a sender or as a receiver)as a function of MTU size(see Figure3).We note that we did not observe any losses and thus the computational cost we measured does not include the TD and TO costs.
In general,we can see that the iPAQ6is indeed far more energy ef?cient than the laptop(with either version of FreeBSD).This is to be expected because the iPAQ uses a low-power StrongARM processor and is optimized for low energy operation.It is important to note that these energy costs represent only the computational energy cost and do not include the idle energy cost which,in the case of the laptop,consists of the cost of the fan,hard disk,CD, screen,etc.
The impact of increasing the MTU size in all cases is to reduce the computational energy cost because the cost of operations such as copy and checksum computation are amortized over more bytes.It is also noteworthy that the impact is higher in the case of the laptop.These behaviors are explained in more detail in section5.2.
In comparing the two versions of FreeBSD,we note that there is no difference in energy cost when the laptop is a receiver.However,when it is a sender,we see that version5is more energy ef?cient(however,since the con?dence intervals of one include the means of the other we cannot make a very strong statement about this difference).
In all three cases,we note that the computational cost of sending is greater than that of receiving.This is expected because the sender does perform more bookeeping tasks such as window management,RTO computation,etc..
However,the three systems show a variance in behavior.The sender in FreeBSDv4.2consumes10%more energy than the receiver whereas the sender in FreeBSDv5consumes only5%more energy.It is dif?cult to pinpoint the reason for this difference in behavior because the TCP/IP code for version5is very different from version4.2 (including the fact the version5implements TCP newreno while version4.2implements reno).Finally,we note that the iPAQ sender consumes15%more energy than an iPAQ receiver.
In Figure4we plot the per packet computational energy cost(excluding the radio transmission/reception cost)as a function of MTU size.As expected,larger packets do cost more to process and there is a linear increase in cost as a function of packet size.The increase is,however,steeper for the case of the laptop.We return to a discussion of this in section5.2.
Figure5plots the throughput of the three systems as a function of MTU size.We see that larger MTU sizes result in higher throughputs.
We note that FreeBSDv5has a higher throughput than FreeBSDv4.2.The reason for this is that the device driver for FreeBSDv5copies data more ef?ciently to the card than the older driver for version4.2(since there were no losses, the TCP?avor,reno vs newreno,has a smaller impact on this difference).
We observe that the throughput of the iPAQ was the lowest of the three even though the TCP implementation in the iPAQ is Newreno.The reason for this behavior is that the802.11b device driver in the iPAQ copies data more slowly than the device driver in the laptop(possibly due to a poorer driver implementation but most probably due to the difference in processor speed–650MHz for the laptop versus200MHz for the iPAQ).
A last comparison we performed between the three systems was a measurement of the relative costs of the radio(i.e.,the transmit and receive costs only)and the computational cost of TCP(as de?ned in section3).These results are shown in Figure6.As we can see,in the case of the laptop,the computational cost accounts for the majority of the total cost of the ttcp connection.The?gures are reversed for the case of the iPAQ where the computational costs are smaller than the radio costs.Finally,note that the radio costs account for a smaller percentage in the case of a receiver.This is because the receive current draw of the802.11b card is smaller than the transmit current draw.
4Also note that the same802.11b card was used in each of the three systems and,furthermore,the same laptop was used for two cases representing FreeBSDv4.2and FreeBSDv5–we simply booted with the appropriate kernel to perform the measurements.
5In the studies reported in this section,i.e.,section5,we did not use the zero-copy option in FreeBSDv5.We use it later in section6.
6We were unable to set the segment size to128bytes for the iPAQ and thus the graphs for the iPAQ do not show this data point.
7
Figure3:Total computational energy costs.
5.2Computational energy cost breakdown
In this section and the next we decompose the total computational cost of TCP into its components as discussed in section 3.Recall that the computational energy can be decomposed into three primary categories:user-to-kernel copy cost,kernel-to-NIC copy cost,and TCP processing cost.The two copy costs are similar at the sender and at the receiver.However,the TCP processing cost is somewhat different.At the sender the TCP processing cost includes checksum,ACK processing, congestion window updates,timeout(TO)processing,triple duplicate(TD)processing,timer processing,RTO computa-tion,and other OS related costs.At the receiver,TCP processing includes ACK generation,checksum computation,data sequencing,receive window management,etc.In this section we decompose the TCP computational cost into the copy costs(user-to-kernel space,kernel-to-NIC)and the TCP processing cost(i.e.,TCP computational cost minus the two copy costs).We further decompose the TCP processing costs in section5.3.
Data sent through a TCP socket is?rst queued in the socket send buffer and it is then copied into kernel space for further processing.In order to determine the cost of performing this copy(that we call user-to-kernel space copy),we implemented a kernel program using the copyin()and copyout()functions.We then ran this program and copied large?les (which were composed of random data).We measured the current draw while this program was running and used this measurement to obtain the user-to-kernel copy cost.To determine the copy cost from the kernel to the NIC card,we used UDP for data transmission.Unlike TCP,data sent through a UDP socket goes all the way down to the network interface and the socket send buffer is not used.
Figure7shows the relative costs(in%)at the sender of the two copy operations and TCP processing for the three systems.As the?gure shows:
By far the most expensive operation is the Kernel–NIC copy cost.This accounts for between60–75%of the total cost incurred at the sender.To better understand these costs,note that the PCMCIA card is not very ef?cient and it takes a signi?cant amount of time to copy the data from memory to the802.11b card.The device driver calls a copy operation for each packet resulting in an interrupt and context switch since the PCMCIA2.1speci?cation does not allow DMA(Direct Memory Access)or bus mastering7.
As a percentage of the total cost,we note that the TCP processing cost increases with a decrease in MTU size.This is explained by the fact that each packet results in the same code being executed on the output(Table1shows the 7It is noteworthy that the new CardBus cards do allow DMA and bus mastering and they run at a lower voltage(3.3V rather than5V)and allowing 32-bit operation.Thus,we expect the overall energy cost of the Kernel–NIC copy cost to be lower for these cards.However,device drivers were not available for these CardBus cards and we were unable to test them for this paper.Furthermore,there are currently very few vendors who manufacture CardBus cards for802.11b(we could only identify one vendor–D-Link).Most of the CardBus cards are targeted at the802.11a standard where greater transfer speeds are required to match the54Mbps transmission speed of the radio.
8
TCP processing cost per packet at the sender as a function of MTU size,as we can see,the processing cost is fairly independent of the MTU size).Thus,smaller MTUs result in more packets sent with the corresponding increase in overall TCP processing cost and hence a larger share of the overall cost.If we view the data in Table1together with Figure4in which we showed a linear increase in per packet cost as a function of MTU size,we can conclude that while the TCP processing cost is independent of MTU size,the cost of copying packets depends on the MTU size and is the primary contributor to total computational cost of TCP.
Figure8plots the same data for the receiver.We note a similar trend as that at the sender with the kernel-to-NIC copy being the dominant factor.However,we note that in general the TCP processing cost is a smaller percentage here than at the sender.This is understandable because the receiver does less TCP processing than the sender.
It is interesting to compare the relative costs for our three systems with the results reported in[8]where the authors report on the time consumed in the TCP stack:user–kernel copy,NIC-to-kernel copy,and processing costs for1460 byte packets.The table below summarizes the costs of our studies and[8]for the case of1460byte segments:
Relative costs at sender
NIC-to-kernel copy kernel-to-user copy TCP processing OS Metric FreeBSDv4.278%16%6%Energy
FreeBSDv577%15%8%”
iPAQ72%15%13%”
[8]40%17%43%Time
As we can see,the relative cost of the kernel-to-user copy operation appears to be relatively unchanged.However,in the three systems we studied,the relative cost of the NIC-to-kernel copy is far greater than in[8].We can conclude that over the past decade while processors have gotten very ef?cient,the bus architecture has not kept pace and the implementation of TCP has gotten more ef?cient(using some techniques described in[8]).Thus,the relative cost of TCP processing(as a fraction of total cost of a TCP connection)today is far smaller than a decade ago.
5.3Breakdown of TCP Processing:Checksum,TO,TD,ACK
As noted at the start of the previous section,the TCP processing cost at the sender and at the receiver is made up of several components.We obtained a breakdown of this processing cost at the sender and receiver into three major categories:
9
checksum,ACK,and“other”,where the“other”piece corresponds to congestion window management,RTO computation, TCP(Transmission Control Block)lookup,etc.We could not decompose the“other”piece further because the resolution of our method was not good enough to give statistically signi?cant data.We note,however,that we did measure the TO and TD energy cost at the sender.
5.3.1Checksum cost
The checksum cost was measured directly by extracting the checksum code from the implementation in the kernel and measuring the current draw of the laptop/iPAQ when running this code repeatedly.Table1provides the result of our measurement.In the table we provide the checksum cost as a percentage of the packet processing cost(this cost excludes the copy costs as well as any radio cost).In the case of the laptop,we see that the checksum computation accounts for approximately30%of the packet processing cost whereas in the iPAQ it accounts for between17–20%only.In view of the fact that the iPAQ runs a more power e?fcient processor at a slower clock speed,this result is not surprising.Interestingly, the cost appears to be the same for the two versions of the FreeBSD kernel thus indicating use of the same algorithm.[8] also reports on the cost of checksum processing for1460byte packets.The relative cost of checksum processing(in terms of time)as a fraction of TCP processing cost is35%–this cost is very similar to the relative checksum cost for the two FreeBSD versions.
5.3.2Determining TO,TD and ACK Costs
In this section,we focus our attention on characterizing the processing cost of TCP’s retransmission mechanism and on determining the cost of processing ACKs at the sender8.Directly measuring the cost of ACKs(processing plus copy cost from the NIC to the kernel)is dif?cult because the actual amount of ACK code is very small(less than ten lines).Thus, we measured the ACK cost by measuring the cost of duplicate ACKs that occur in the event of lost packets.We therefore folded the ACK cost measurement in with the measurement of TO and TD events.
When packets are lost,the TCP sender recovers from the loss by either the fast retransmit mechanism or via slow-start after a timeout occurs.In order to compute the cost of responding to TD or TO events,we needed to use indirect methods because it is virtually impossible to directly measure the current draw when either of these events occur(the timescale is too small to allow the multimeters,which have a resolution of one millisecond,to capure the data reliably).
8Since almost all of the ACK cost is explained by the NIC-to-kernel copy cost,we observed that the ACK cost at the sender was the same as the cost at the receiver(within statistical error).
10
1.First,we included counters inside the TCP/IP code to count how many TD and TO events occurred during a session.
We also separately counted the number of Duplicate ACKs received(excluding triple duplicate ACKs).
2.We ran Dummynet[23]at a node in the path of the connection so that we could enforce losses.This was needed in
order to force TO and/or TD events at the sender.
3.Let denote the computational cost of TCP at the sender for transmitting1MByte of data with-out loss(this corresponds to the data discussed in section5.1)using a given MTU.Let de-note the computational energy cost when there were losses created by Dummynet.Then,
gives us the total retransmission cost for the session.Speci?cally,
TO&TD Processing Cost Duplicate ACK copy&processing cost
Kernel–NIC Copy Cost for Retransmitted Packets
4.We used tcptrace and tcpdump to monitor all packets from the?ow and thus determined the actual number of
retransmitted packets(say).In section5.2we had measured the kernel-to-NIC copy cost of packets.We thus determine the energy()for processing TO,TD,and ACKs as,
Kernel-to-NIC Copy Cost for Reransmitted Packets
5.Recall that we count the number of times TO,TD,and Duplicate ACKs that occur during a connection.We can thus
write,
TD Cost TO Cost Dup ACK Cost(2) where denote the value of the counters for each of these events.
11
6.We ran several experiments with different loss rates and obtain several sets of linear equations(2).These equations
are then solved in sets of three to obtain values for the processing cost of TD and TO,and the cost of ACKs.We ran over100such experiments in order to obtain enough data to compute95%con?dence intervals.
We summarize the results of these studies in Table2.We can make the following observations:
The cost of TO and TD processing is signi?cantly greater than the cost of normal TCP packet processing(see Table
1).
The ACK cost is fairly high and is almost entirely made up of the cost of copying the ACK from the NIC card to the kernel(Figure12shows the relationship between copy costs and copy size).We observed that the ACK cost,as measured using equation(2),is almost the same as the cost of copying the ACK to the kernel from the NIC.Thus, we ignore the the energy draw for the execution of the9–10instructions dealing with ACK processing.
5.4Validation
In order to validate our measurements presented in the previous sections,we ran experiments in which10MByte of data was sent to a remote host at the other side of the country.We measured the total energy consumed by the connection and
12
MTU15001000552296168
TCP
processing1,5891,5881,5831,5771,513 Laptop(J)
(FreeBSDv4.2)Cksum Cost
(J)514504463444424
%32.33%31.73%29.27%28.14%28.05%
TCP
processing1,5461,5141,5201,4891,416 Laptop(J)
(FreeBSDv5)Cksum Cost
(J)512502462443422
%32.13%33.14%30.42%29.72%29.81%
TCP
processing761758730726 iPAQ(J)
(Linux)Cksum Cost
(J)153143130126
%20.07%18.85%17.78%17.32%
Table1:Sender-side TCP processing cost and checksum processing cost.
MTU150095%CI MTU55295%CI FreeBSDv4.2TD Processing Cost2,4061902,402131 (J)TO Processing Cost2,710332,592123 ACK Cost(Mainly Copy)1,209361,17111 FreeBSDv5TD Processing Cost2,3801022,37932 (J)TO Processing Cost2,660922,52952 ACK Cost(Mainly Copy)1,188171,1645 iPAQ TD Processing Cost1,0511621,015132 (J)TO Processing Cost1,3021071,16115 ACK Cost(Mainly Copy)1762517517 Table2:Summary of TO and TD processing costs and ACK Costs.
13
computed the estimated energy as well.The estimated energy was detetermined by simply using the energy costs derived in sections5.2and5.3:
Estimated Energy(10MB,MTU)user-to-kernel Copy10MByte Normal TCP Processing Cost
Kernel–NIC Copy for given MTU size
TD Cost TO Cost Num ACKs ACK Cost
where is the number of packets sent(not counting retransmissions)and MTU indicates the MTU size used.For the vali-dation experiments we only used MTU sizes of1500and552.The actual values used for the various costs are summarized in Table3.Table4displays some representative measured and estimated energy values for the case when the MTU was 1500(The DUP ACK column counts the duplicate ACKs only–the total number of ACKs is the number of duplicate ACKs plus approximately the number of congestion windows transmitted).As we can see,the difference between the estimated values and the actual measured values is very small(less than0.1%).Similar results were obtained for a MTU of552.
5.5Summary
We can summarize the results of this section as follows:
14
FreeBSDv4.2
J MTU1500MTU552
Normal TCP Proc.1,5891,583
TD Cost2,4062,402
TO Cost2,7102,592
ACK Cost1,2091,171
Kernel–NIC Copy16,2516,744
user-to-kernel Copy1417344
FreeBSDv5
J MTU1500MTU552
Normal TCP Proc.1,5461,520
TD Cost2,3802,379
TO Cost2,6602,529
ACK Cost1,1881,164
Kernel–NIC Copy15,2076,293
user-to-kernel Copy30151058
iPAQ
J MTU1500MTU552
Normal TCP Proc.761726
TD Cost1,0511,015
TO Cost1,3021,161
ACK Cost176175
Kernel–NIC Copy4,4132,109
user-to-kernel Copy916321
Table3:Parameters used in validation study.
TO TD Dup Total Computed Total Measured Difference ACK(J)(J)%
FreeBSDv4.2
5812455112,916,459112,830,7040.08% 2234931416121,109,506121,747,4560.52% 478412112,685,425112,719,5440.03% 111110111,783,380111,793,7600.01% 135********,759,417115,298,1120.47%
FreeBSDv5
4510371112,473,503112,624,0480.13% 2911233112,046,029112,107,4870.05% 1681251,303117,798,661118,682,4060.74% 372482,348121,252,172122,318,0690.87% 3917288112,394,444112,304,6370.08%
iPAQ
6411939,532,61839,534,2250.005% 457570239,857,32939,890,9400.08% 147771939,793,19639,828,5730.09% 167670039,792,62739,813,5180.05% 201028739,604,59439,616,0890.03% Table4:Sample validation results(MTU1500Bytes).
15
The prmary contributor to TCP’s computational cost is the kernel–NIC copy operation accounting for almost70% of the total cost.
The TD,TO,and ACK processing costs can be determined by using an equation based approach.The cost of TD and TO processing is approximately60%greater than the normal processing cost of TCP(on a per packet basis).
The implementation of the device driver for the NIC card makes a signi?cant difference in the kernel-to-NIC copy cost as well as in the overall throughput seen.
6Techniques to reduce the energy cost of TCP
In order to reduce the computational cost of TCP without modifying the architecture of the node,we examine two avenues: eliminating the user-to-kernel copy cost and minimizing the kernel-to-NIC copy cost.The?rst cost can be eliminated by employing zero copy where the user data is copied directly from the socket layer to the NIC.Minimizing the kernel-to-NIC copy involves putting more functionality in the NIC card.We discuss the impact of implementing zero copy in the next section and we describe two approaches for minimizing the kernel-to-NIC copy cost in section6.2.
6.1Using Zero Copy
We used zero copy in FreeBSDv5and re-ran the experiments described in section5above.Figure9plots the total computational energy cost(equation(1))at the sender and receiver.As we can see,using zero copy does reduce the total energy cost at both the sender and at the receiver.As indicated in the?gure,this reduction is as much as14%when using the maximum MTU size.Figure10plots the throughput with and without zero copy.Interestingly,we see a signi?cant improvement in throughput when using zero copy.Thus,using zero copy not only reduces the computational energy but it also increases throughput signi?cantly.
Figure9:Total computational energy costs with and without zero copy.
6.2Reducing the kernel-to-NIC copy cost
The kernel–NIC copy cost is by far the largest contributor to TCP’s computational energy cost thus we need to develop mechanisms to reduce this cost within the context of the given hardware9.We have investigated two complimentary 9As noted earlier,using a CardBus card instead of a PCMCIA card will reduce the cost to some extent due to the lower voltage used(3.3V),the wider bus(32-bit),and DMA.
16
Figure10:Throughput with and without zero copy.
mechanisms that will enable us to reduce this cost:
1.Maintain TCP’s send buffer on the NIC card itself,and
2.Maximize the data transfer size from the kernel to the NIC card.
If we maintain TCP’s send buffer on the NIC card,the bene?t we get is that we save signi?cant amount of energy on all retransmissions since the packets will not need to be copied from the kernel to the NIC card again.Refer to Table3where we give a breakdown of the cost of processing TO and TD events as well as the copy costs.To take an example,if we are running FreeBSDv5,in the case of a TO,the total cost of retransmitting the packet is J.However,if the packet is already present in the NIC card,the cost of this TO will only be J.Thus,we see signi?cant savings when there are many retransmitted packets as can happen in wireless environments.Note,however,that the kernel needs to have a way to tell the NIC card to retransmit a speci?c packet from the send buffer.Also,if the host has several open TCP connections,a separate buffer will need to be maintained for each connection.
We ran experiments in which an intermediate node was con?gured to drop packets using Dummynet.Three loss rates were used–1%,5%,and10%and we counted the number of TO and TD events for each run.We used the data in Table 3to then estimate the extent of energy savings possible if the send buffer was kept at the NIC card.Figure11plots the energy savings possible(the righthand plot)for the FreeBSDv4.2system.As we can see from the left-hand plot,at a low loss rate,the number of TO and TD events is small(for all MTU sizes)and thus the energy savings are approximately1%. However,at higher losses,the energy savings are more signi?cant–4%at a5%loss rate and10%at a10%loss rate.
The second mechanism we looked at for reducing the cost of kernel–NIC copy costs has to do with the data copy size.Figure12plots the kernel-to-NIC copy cost for copying1MByte of data as a function of the individual data chunks copied.As is clear from this?gure,it is better to copy data to the NIC card in larger chunks since this reduces the total number of interrupts and context switches.In fact,the difference between using1460bytes versus the smallest size is 2X for FreeBSD and1.4X for the iPAQ.Thus,in order to reduce the cost of the kernel-to-NIC copy,it is best to use the largest data size possible for this copy operation10.However,there is a problem with this approach.Typically,each write to the NIC card corresponds to one packet.Thus,the NIC card automatically knows about packet boundaries.If,however, we copy several packets at once(say the whole send buffer)then we need to have some way of informing the NIC card about packet boundaries.In order to implement the two mechanisms described in this section,the device drivers need to be modi?ed in order to allow send buffers to be maintained on the card and a way for the kernel to inform the card of packet boundaries and which packets to retransmit.
10We did not experiment with even larger data copy sizes.However,the expectation is that the energy needed will be smaller.The only restriction on maximizing the data copy size is the hardware limitation on how long a device can capture the bus.
17
Figure11:Reduction in total computational energy with NIC-based window.
6.3Discussion
In this section we have descibed three mechanisms that can be used to reduce the cost of TCP connections.If we put these together,we can estimate the overall energy savings possible.Let us say that the optimum MTU size to use(given channel error rates,etc.)is552bytes.Then,we save10%using zero copy,another4–10%by maintaining the send buffer on the NIC card,and,if we copy data in large chunks(say1460byte chunks)then we save15%(of the kernel–NIC copy cost) or10%of the total cost.Thus,we can reduce the overall cost at the sender by between24%and30%for an MTU size of 552.
It is interesting to note that the techniques we describe above for reducing energy consumption are similar to the ones described by various authors for making TCP support high-speed networking!
7Conclusions
We developed measurement techniques to allow us to indivudually measure the energy cost of separate logical operations performed in TCP/IP at the sender and receiver.We then used these measurements to develop approaches in software that will allow us to reduce the cost of TCP processing by between20%and30%in most cases.These approaches provide us with valuable information on how to modify device drivers and the architecture of NIC cards for mobile computing. Finally,our measurements can be used to enhance simulators such as NS-2to include node-level energy models.This, in combination with existing radio energy models,will give researchers the capability to study energy consumption in arbitrary wireless networks.
References
[1]Ns-2:https://www.doczj.com/doc/4216320847.html,/nsnam/ns/,2002.
[2]Mark Allman,Chris Hayes,Hans Kruse,and Shawn Ostermann.Tcp performance over satellite links.In5th Inter-
national conference on telecommunication systems.
[3]D.C.ANderson,J.S.Chase,S.Gadde,A.J.Gallatin,K.G.Yokum,and M.J.Feeley.Cheating the i/o bottleneck:
Network storage with trapeze/myrinet.In Proceedings1998USENIX Annual Technical Conference,pages143–154, June1998.
18
Figure12:Kernel–NIC copy as a function of copy size.
[4]R.Bruyeron,B.Hemon,and L.Zhang.Experimentations with tcp selective acknowledgement.ACM Computer
Communications Review,1998.
[5]J.Chase,A.Gallatin,and K.Yocum.End system optimizations for high-speed TCP.IEEE Communications Maga-
zine,39(4):68–74,2001.
[6]H.K.Jerry Chu.Zero-copy TCP in solaris.In USENIX Annual Technical Conference,pages253–264,1996.
[7]David Clark and David Tennenhouse.Architectural considerations for a new generation of protocols.In ACM
SIGCOMM’90,September1990.
[8]David D.Clark,Van Jacobson,John Romkey,and Howard Salwen.An analysis of tcp processing overhead.IEEE
Communications Magazine,27(6),June1989.
[9]Zubin D.Dittia,Guru M.Parulkar,and Jerome R.Cox.The apic approach to high performance network interface
design:Protected dma and other techniques.In IEEE INFOCOM’97,1997.
[10]P.Druschel,M.Abbot,M.Pagels,and https://www.doczj.com/doc/4216320847.html,work subsystem design.IEEE Network,7(4):8–17,July
1993.
[11]Sorav Bansal et.al.Energy ef?ciency and throughput for tcp traf?c in multi-hop wireless networks.In Proceedings
INFOCOM2002,New York,NY,2002.
[12]Laura Feeny and Martin Nilsson.Investigating the energy consumption of a wireless network interface in an ad hoc
networking environment.In Proceedings INFOCOM2001,Anchorage,Alaska,2001.
[13]Paul Gauthier,Daishi Harada,and Mark Stemm.Reducing power consumption for the next generation of pdas:It’s
in the network interface.In Proceedings of MoMuC’96.
[14]Tim Henderson and Randy Katz.Transport protocols for internet-compatible satellite networks.In IEEE Journal on
Selected Areas of Communications,February1999.
[15]Hsiao-Keng and Jerry Chu.Zero-copy tcp in solaris.In USENIX1996Annual Technical Conference,January1996.
[16]https://www.doczj.com/doc/4216320847.html,.Sycard technologies,pccextend140cardbus extender,July1996.
19
[17]K.Kleinpaste,P.Steenkiste,and B.Zill.Software support for outboard buffering and checksumming.In ACM
SIGCOMM’95,August1995.
[18]Shawn Osterman.tcptrace:Tcp dump?le analysis tool.https://www.doczj.com/doc/4216320847.html,/software/,2002.
[19]M.Srivastava P.Lettieri,C.Schurgers.Adaptive link layer strategies for energy ef?cient wireless networking.In
Wireless Networks,volume5,pages339–355,1999.
[20]Jitedra Padhye,Victor Firoiu,Don Towsley,and Jim Krusoe.Modeling TCP throughput:A simple model and its
empirical validation.In ACM SIGCOMM’98conference on Applications,technologies,architectures,and protocols for computer communication,pages303–314,Vancouver,CA,1998.
[21]Craig Partridge.Gigabit Networking.Addisson-Wesley,1993.
[22]M.Rangarajan,A.Bohra,K.Banerjee,E.V.Carrera,R.Bianchini,and L.Iftode.Tcp servers:Of?oading tcp process-
ing in internet servers.design,implementation,and performance.Technical Report dcs-tr-481,Rutgers University, Department of Computer Science,March2002.
[23]L.Rizzo.Dummynet:a simple approach to the evaluation of network protocols.ACM Computer Communication
Review,27(1),January1997.
[24]P.Shivam,P.Wyckoff,and D.Panda.Emp:Zero-copy os-bypass nic-driven gigabit ethernet message passing.In
SC2001.
[25]B.Sikdar,S.Kalyanaraman,and K.S.Vastola.An integrated model for the latency and steady-state throughput of
tcp connections.Performance Evaluation,2001.
[26]H.Singh and S.Singh.Energy consumption of tcp reno,newreno,and sack in multi-hop wireless networks.In ACM
SIGMETRICS2002,June15-192002.
[27]V.Tsaoussidis,H.Badr,X.Ge,and K.Pentikousis.Energy/throughput tradeoffs of tcp error control strategies.In In
Proceedings of the5th IEEE Symposium on Computers and Communications,France,July2000.
[28]Gary R.Wright and W.Richard Stevens.TCP/IP Illustrated,Volume I(The Protocols).Addison Wesley,1994.
[29]M.Zorzi and R.R.Rao.Error control and energy consumption in communications for nomadic computing.In IEEE
Transactions on Computers,March1997.
[30]M.Zorzi and R.R.Rao.Is tcp energy ef?cient?In Proceedings IEEE MoMuC,November1999.
[31]M.Zorzi,M.Rossi,and G.Mazzini.Throughput and energy performance of tcp on a wideband cdma air interface.
In Journal of Wireless Communications and Mobile Computing,Wiley2002,2002.
20
东方财富通可用的指标公式（一） TBP-STD 趋势平衡点主图 APX:=(H+L+C)/3; TR0:=MAX(H-L,MAX(ABS(H-REF(C,1)),ABS(L-REF(C,1)))); MF0:=C-REF(C,2); MF1:=REF(MF0,1); MF2:=REF(MF0,2); DIRECT1:=BARSLAST(MF0>MF1 AND MF0>MF2); DIRECT2:=BARSLAST(MF0
E-Net2.0 ENE非线性编辑软件操作手册目录 目录 (1) 前言 (2) 审片软件操作指南 (3) 1. 系统登录 (3) 2. 节目管理 (3) 1)打开节目 (4) 2)刷新 (6) 3)退出 (6) 3. 节目审看 (7) 1)播放节目 (7) 2)记录审查意见 (8) 3)节目处理 (8) 4. 退出系统 (9)
前言 感谢您选用成都索贝数码科技股份有限公司（Sobey Digital Technology Co., Ltd）的E-Net 2.0 ENE编辑网络系统。 索贝E-Net是索贝公司全力打造的制播一体化网络新产品，是一个具有 新闻共享、制作、播出、小媒资管理和网络管理的全数字环境的智能化新 闻节目制播网络系统。ENE是索贝E-Net系统中的制作部分，它能支持电 视台新闻业务的运作，并承担电视台大部分新闻节目生产任务。系统实现 收录和自采新闻节目素材的全台共享，充分利用计算机多媒体技术和网络 技术，全面提高电视台新闻节目的制作水平和播出效率。 索贝E-Net非线性编辑网络系统是我公司自主开发的一套全中文的非线 性广播级节目制作系统，它能广泛地适用于广播电视单位，各种电视教育 以及各类广告的制作。E-Net非编系统采用数字视频技术发展方向的MPEG 2压缩方式，将编辑、字幕、节目包装“三位一体”化，并以完善的素材、节 目管理机制全面兼容ENC网络，是索贝公司为新开发的新一代全新的非线 性编辑系统。 本手册适用于系统操作人员、电视台编辑、记者。本手册的主要目的是 对E-Net2.0审片软件的实际操作提供指南。
E-Net2.0 ENE非线性编辑软件操作手册审片软件操作指南 1. 系统登录 在进入E-Net审片系统进行审片之前，用户必须具有审片相应的权限， 权限可以在网管软件中进行设置。具体操作见《网络管理工作站操作手册》。 启动E-Net审片系统，将出现下面登录窗口，如图1-1-1： 图1-1-1 2. 节目管理 本模块主要用于在节目列表中选择需要进行审看的节目。 操作步骤 输入用户名及密码后，点击【确定】，进入节目管理窗口，如图1-2-1， 用户可以看到所有栏目及栏目下所有节目信息，
东方财富通指标说明 一、技术指标 (1) 1、ADTM动态买卖气指标： (1) 2、AMOUNT成交金额： (1) 3、ASR浮筹比例： (1) 4、ATR真实波幅： (1) 5、BBI多空指标： (2) 6、BBIBOLL BBIBOLL： (2) 7、BIAS乖离率： (2) 8、BIAS36三六乖离： (3) 9、BIAS_QL乖离率-传统版: (3) 10、BOLL布林线: (3) 11、BOLL副图布林线: (4) 12、BRAR情绪指标： (4) 13、BTX宝塔线(副图)： (4) 14、CCI商品路径指标： (5) 15、CHO济坚指数 (5) 16、CR带状能量线 (6) 17、CSI股票选择指标 (6) 18、CYD承接因子 (6) 19、CYF市场能量 (7) 20、CYQKL博弈K线长度 (7) 21、CYR市场强弱 (7) 22、CYS市场盈亏 (8) 23、CYW主力控盘 (8)
25、DMA平均差 (9) 26、DMI趋向指标(标准) (9) 27、DMI_QL趋向指标(钱龙) (10) 28、DPO区间震荡线 (10) 29、DPTB大盘同步 (11) 30、EMV简易波动指标 (11) 31、ENE轨道线 (11) 32、EXPMA指数平均线 (11) 33、FSL分水岭 (12) 34、HSL换手率 (12) 35、KD随机指标 (12) 36、KDJ经典版KDJ (12) 37、LON钱龙长线 (13) 38、LWR威廉指标 (13) 39、MA均线 (13) 40、MACD平滑异同平均 (14) 41、MASS梅斯线 (14) 42、MFI资金流量指标 (14) 43、MIKE麦克支撑压力 (15) 44、MTM动量线 (15) 45、NDB脑电波 (16) 46、NVI负成交量 (16) 47、OBV累积能量线 (16) 48、OSC变动速率线 (17) 49、PB市净率 (17) 50、PBX瀑布线 (17)
R-6 关键词 X1 生活相关 Y2 机器 Z2 石油类 F18 petroleum NIPPON OIL CORPORATION 家庭用燃料电池 ENE?FARM ◆ 家庭用燃料电池 ENE?FARM是能够同时产生电气和热水的同时供给（Co-Generation）系统。 ◆ 发电所产生的电量最多可以提供一个标准家庭用电量的约60%。※ ◆ ＥNE?FARM所产生的热水可以供浴室、厨房、盥洗室等各种场所使用。 ※因不同家庭的使用状况、不同季节而异。 家庭用燃料电池 ENE?FARM通过从LPG、煤油或者城市煤气中提取的氢与空气中的氧发生电化学反应来发电。同时还回收发电时产生的热来制造热水。
R-6 由于家庭用燃料电池 ENE ?FARM 通过氢与氧的电化学反应来发电，因此几乎不产生会造成酸雨的氮氧化物（NOx ）以及硫氧化物（SOx ）。另外，由于其能效较高，占温室效应气体大半部分的二氧化碳（CO2）的排放量也比传统系统减少最多可达30％。 （※因不同家庭的使用状况、不同季节而异） 另外，由于是在家中发电，因此不存在输电时的电力损耗。并且，由于可以有效利用发电时产生的热量用于热水供给，能效约为80％，比传统系统更高。联系方式： NIPPON OIL CORPORATION Fuel Cell & Solar Cell Planning Group Fuel Cell & Solar Cell Business Dept. Energy System Business Division TEL +81-3-3502-9243 FAX +81-3-3502-4749 HP http://www.eneos.co.jp/lande/product/fuelcell/日本国内在（财）新能源财团实施的固定场所设置用燃料电池大规模实践事业中，本公司预定于2008年度 设置总计507台ENE·FARM ，其中LPG 设备413台、煤油设备83台、城市煤气设备11台。 2005～ 2008年度的设置数量（累计）合计为1,368台，其中LPG 设备1,053台、煤油设备304台、 城市煤气设备11台。占到了大规模实践事业总的预定设置数量（累计3,307台）的41％，是事业参与者中所占比例最多的。 海外2009年度开始首次在日本国内市场销售。预定将在适当时机开展海外市场。 Fiscal year 2005 2006 2007 2008 Total (units) Nippon Oil Co. 142 311 408 507 1,368 (Company Share) (30％) (40％) (44％) (45％) (41%) Grand total 480 777 930 1,120 3,307 ＊
ENE指标_第一集ENE指标：颠覆你传统操作的秘技-1 ENE指标_第二集ENE指标：颠覆你传统操作的秘技-2 ENE指标_第三集ENE指标：颠覆你传统操作的秘技-3 ENE指标_第四集ENE指标：颠覆你传统操作的秘技-4 （以上见2013年股市聊聊吧） 再聊ene指标见（2014年股市聊聊吧） ENE轨道线参数设定（2014） 以招商证券为例，先打开招商证券的软件（应该跟英强说的通达信是一样的，因为招商证券的键盘输入显示就是通达信键盘精灵），随便点击一只股票，会进入如下界面： 键盘输入ene三个字母，会出现如下界面：
右键点击左上角ene指标，会弹出如下界面：
选择调整指标参数，按照下图调整指标参数： 廖英强的博客指标的（ENE）（2014）
这几天来信问这个指标的（ENE）的很多，我在这里讲解一下，如何操作。进到任何一个证券公司都可以。下载通达信软件，免费的。如果需要账号和密码，的请点击独立行情就可以进入。 在技术分析画面，直接敲ENE回车就可以看到该指标。在画面上方有UPPER：***字母和数字。将鼠标点在数字时按鼠标右键，可以看到调整指标参数，或按ALT+T。也可以看到画面会出现25 6 6.将第一个数值换成10第二个数值换成11第三个换成9就可以了。希望在家里利用休息时间看看自己为什么被套，最好找些原因。本指标很简单，明白高抛低吸的精髓。很多人以前都不知道，在股市里他是我常用的指标之一。跟了我15年了，今天传授给你，望大家好好使用。另外还有其他技术我会在节目里慢慢讲解的。让大家了解什么是技术派。 我们正好在这个时间段讲解ENE技术目的是让大家在震荡市里也可以有钱赚。开始时希望您模拟操作，或是少量跟进，切不可满仓进出，因为下轨的位置都是主力买货的时候，当他发现有很多人和他抢，他会洗盘的，所以权重股到下轨那可是真的给大家送钱那，小盘股操作一定要小心。看博客的观众慢慢体会我在前几期博客里为什么和大家说，银行地产保险券商调整已经到位会有5-7%以上的涨幅了原因了吧。我体会了十五年也希望你们好好地利用它，为你自己创造财富，当然还有其他更神奇的指标在以后的节目里再讲。 这几天很多人因为ENE这个指标感觉看到了希望，我只是
ENE轨道线实战技巧 转载了天赐钱缘的博文 ENE轨道线跟布林带指标类似，由3条线组成；轨道的宽度不会像布林带出现放大或缩小的变化。 在实战中，ENE不仅可以敏锐的发现股价运行方向的变化，还可以给我们提供有效的操作信号提示，下面是操作的5条法则。 一、ENE走平，股价突破中轨，放量站上12天均量线，为买入信号 如易联众（300096），2015年1月7日股价上穿ENE中轨，持续三天维持站稳中轨，这就是一个很好的买入时机，后再次放量，迎来一波翻倍大涨。 二、ENE向上运行，股价跌至下轨附近，没有跌穿下轨，重新上涨可以买入
如宜华地产（000150）2014年10月23日，24日及27日这三天股价都在下轨附近运行，但是却没有跌穿下轨，所以说是一个在低位建仓的好时机，后期这一个波段做下来，拿得住的差不多会得到一倍的利润。 三、ENE向上运行，股价穿越上轨买入；掉头向下跌穿上轨，可以卖出
如滨江集团（002244），在2015年3月3日放量涨停突破上轨，第二天上轨附近低吸买入；再看3月17日这天，已经跌至上轨之下了。如此快速的冲高回落也预示着短期走势破坏，这时可以先离场，等待低位再次入场。 四、ENE向下运行，股价涨至上轨附近，出现下跌没碰到上轨，也可以卖出
如林州重机（002535）ENE处在下行状态，股价反弹至上轨附近，这时要注意了，如果股价又掉头向下运行，建议不要抱有侥幸心理，卖出是个理智客观的选择。 五、单边上涨或下跌，急速上涨，突破上轨买入；急速下跌，跌破下轨卖出 这个比较简单，股价急速上涨，一旦突破上轨，代表进入强势状态，可以买入；股价急速下跌，并跌破下轨，还继续往下跌的，此时趋势已经破坏，就要顺应趋势，及时止损。 重要提醒：1、ENE轨道线只适合日线，不适合其他周期的分析。 2、一种是默认的参数（25,6,6）灵敏，另一种（10,11,9）宽松，找适合自己的。 3、上穿下穿都看实体，上下影线不算。 附ENE指标源代码： n(2,250,10); m1(2,100,11); m2(2,100,9); UPPER:(1 M1/100)*MA(CLOSE,N); LOWER:(1-M2/100)*MA(CLOSE,N); ENE:(UPPER LOWER)/2;
主图指标说明 注：查找请按CTRL+F键，输入关键词查询。 [MA]均线 1.股价高于平均线，视为强势；股价低于平均线，视为弱势 2.平均线向上涨升，具有助涨力道；平均线向下跌降，具有助跌力道； 3.二条以上平均线向上交叉时，买进； 4.二条以上平均线向下交叉时，卖出； 5.移动平均线的信号经常落后股价，若以EXPMA 、VMA 辅助，可以改善。[MA2]均线 在MA均线的基础上增加120日均线和250日均线。
[BBI]多空指标 1.股价位于BBI 上方，视为多头市场； 2.股价位于BBI 下方，视为空头市场。[EXPMA]指数平均线 1.EXPMA 一般以观察12日和50日二条均线为主； 2.12日指数平均线向上交叉50日指数平均线时，买进； 3.12日指数平均线向下交叉50日指数平均线时，卖出； 4.EXPMA 是多种平均线计算方法的一； 5.EXPMA 配合MTM 指标使用，效果更佳。
一般移动平均线以收盘价为计算基础，高价平均线是以每日最高价为计算基础。目前市场上许多投资人将其运用在空头市场，认为它的压力效应比传统平均线更具参考价值。 [LMA]低价平均线 一般移动平均线以收盘价为计算基础，低价平均线是以每日最低价为计算基础。目前市场上许多投资人将其运用在多头市场，认为它的支撑效应比传统平均线更具参考价值。
1.股价高于平均线，视为强势；股价低于平均线，视为弱势； 2.平均线向上涨升，具有助涨力道；平均线向下跌降，具有助跌力道； 3.二条以上平均线向上交叉时，买进； 4.二条以上平均线向下交叉时，卖出； 5.VMA 比一般平均线的敏感度更高，消除了部份平均线落后的缺陷。[BOLL-M]布林线-主图叠加 1.股价上升穿越布林线上限时，回档机率大； 2.股价下跌穿越布林线下限时，反弹机率大； 3.布林线震动波带变窄时，表示变盘在即； 4.BOLL须配合BB 、WIDTH 使用。
在趋势行情中利用周ENE不会破上轨原则捂股趋势行情的一大共性就是股价不会跌破周ENE上轨，可以此作为中、长线持股的依据，坚持在周ENE上轨之上放足利润。 ㈡、在股市震荡筑底期间，利用ENE波段操作，暴跌时要敢于逢低吸纳，反弹上冲时要坚决逢高减磅。 1、底部扭转ENE，若上轨之上接连出现两到三根一阳包数线的光头阳线，是黑马飚涨的重要信号。 2、底部扭转ENE，强势冲出上轨后回跌至中轨时不破，在出现有效上分形时是应该买进。 3、底部的上行ENE，如果股价跌至下轨线附近后重新恢复上涨行情时，即使股价没有击穿下轨线也可以买入。 4、底部的上行ENE，如果股价上涨穿越上轨线后，很快掉头下跌并跌穿上轨线时可以卖出。 5、底部横盘ENE，股价第一次穿越上轨后必然回到轨道内，此时若在中轨止跌形成上分形，则可以买进，当由中轨向上再次放量穿越上轨时要加码买进。此后ENE扭转上行，股价在上轨之上的每一个上分形都是有效买点。但一跌破上轨就要立马出逃。 6、底部的下行ENE，如果股价跌穿下轨线后，很快重新上涨并带量穿越下轨线时可以买入，量能不济出。 7、底部的下行ENE，如果股价涨至上轨线附近后，出现掉头下跌时，即使股价没有触及上轨线要卖出。 ㈢、利用ENE轨道线狙击强势股当股价有效突破日通道线，说明股价已打破原来平衡态势，有可能是股价开始大幅拉升的启动点。如果一只个股经过较长时间持续整理后，突然某一天股价开始放量有效突破轨道线的上轨，那么说明这只个股经过前期的吸筹、洗盘、震仓后，就有可能形成最后的主升行情，在这里，轨道线的上轨就起到很好的主升浪行情的监测作用。所谓有效突破轨道线的上轨，一般要求涨幅在3%以上，并且最好能连续三天在轨道线之上。 五、利用轨道线狙击强势股应该注意以下几点 第一，要求突破轨道线的有效性，即离突破后的上轨要有3%的升幅，最好当日要以光头阳线报收，并且要求连续二三天在轨道线之外放量上冲。 第二，一般要求在股市非常活跃时期，该股短期内未被充分炒作过，在突破上轨前股价处于循环低点，MACD指标在O轴附近交叉向上形成黄金交叉。 第三，要注意当大势持续了3-5个月的牛市行情后，大盘指标有顶背离，量背离的情况时，注意多头陷阱。一些主力资金控盘的个股为拉高出货，先扬后抑，一旦放量突破上轨后，成交量不跟，又回到上轨之下时，应注意止损离场 三线粘合： AA:=MA(C,5); BB:=MA(C,10); DD:=MA(C,30); A1:=ABS((AA-C)/C); A2:=ABS((BB-C)/C); A3:=ABS((DD-C)/C); B:=A1<0.05 AND A2<0.05 AND A3<0.05; FILTER(B,10)=1 ; 多条均线粘合： a13:=ma(c,13); a21:=ma(c,21); a34:=ma(c,34);
重庆市规划局建筑工程经济技术指标 复核标准 一、建筑工程建筑面积计算规范（GB/T 50353-2005） （一）、总则 1.0.1 为规范工业与民用建筑工程的面积计算，统一计算方法。制定本规范。 1.0.2 本规范适用于新建、扩建、改建的工业与民用建筑工程的面积计算。 1.0.3 建筑面积计算应遵循科学、合理的原则。 1.0.4 建筑面积计算除应遵循本规范，尚应符合国家现行的有关标准规范的规定。 （二）、术语 2.0.1 层高 story height 上下两层楼面或楼面与地面之间的垂直距离。 2.0.2自然层高 floor 按楼板、地板结构分层的楼层。 2.0.3架空层 empty space 建筑物深基地或坡地建筑吊脚架空部位不回填土石方形成的建筑空间。 2.0.4走廊 corridor gallery 建筑物的水平交通空间。 2.0.5挑廊 overhanging corridor
挑出在建筑物外墙的水平交通空间 2.0.6檐廊 eaves gallery 设置在建筑物底层出檐下的水平交通空间。 2.0.7回廊 cloister 在建筑物门厅、大厅内设置在二层或二层以上的回形走廊。 2.0.8门斗 foyer 在建筑物出入口设置的起分隔、挡风、御寒等作用的建筑过渡空间。 2.0.9建筑物通道 passage 为道路穿过建筑物而设置的建筑空间。 2.0.10架空走廊 bridge way 建筑物与建筑物之间，在二层或二层以上专门为水平交通设置的走廊。 2.0.11勒脚 plinth 建筑物的外墙与室外地面或散水接触部位墙休的加厚部分。 2.0.12围护结构 enevlop enclosure 围合建筑空间四周的墙体、门、窗等。 2.0.13围护性幕墙 enclosing curtain wall 直接作为外墙起围护作用的幕墙。 2.0.14装饰性幕墙 decorative faced curtain wall 设置在建筑物墙体外起装饰作用的幕墙。 2.0.15落地橱窗 french window
3月9日廖英强的博客指标的（ENE） (2013-03-09 06:49:18) 这几天来信问这个指标的（ENE）的很多，我在这里讲解一下，如何操作。进到任何一个证券公司都可以。下载通达信软件，免费的。如果需要账号和密码，的请点击独立行情就可以进入。 在技术分析画面，直接敲ENE回车就可以看到该指标。在画面上方有UPPER：***字母和数字。将鼠标点在数字时按鼠标右键，可以看到调整指标参数，或按ALT+T。也可以看到画面会出现25 6 6.将第一个数值换成10第二个数值换成11第三个换成9就可以了。希望在家里利用休息时间看看自己为什么被套，最好找些原因。本指标很简单，明白高抛低吸的精髓。很多人以前都不知道，在股市里他是我常用的指标之一。跟了我15年了，今天传授给你，望大家好好使用。另外还有其他技术我会在节目里慢慢讲解的。让大家了解什么是技术派。 我们正好在这个时间段讲解ENE技术目的是让大家 在震荡市里也可以有钱赚。开始时希望您模拟操作，或是少量跟进，切不可满仓进出，因为下轨的位置都是主
力买货的时候，当他发现有很多人和他抢，他会洗盘的，所以权重股到下轨那可是真的给大家送钱那，小盘股操作一定要小心。看博客的观众慢慢体会我在前几期博客里为什么和大家说，银行地产保险券商调整已经到位会有5-7%以上的涨幅了原因了吧。我体会了十五年也希望你们好好地利用它，为你自己创造财富，当然还有其他更神奇的指标在以后的节目里再讲。 这几天很多人因为ENE这个指标感觉看到了希望，我只是让大家了解做股票还有另一种挣钱的方法，在这再讲一下应该怎样使用，第一步，下载软件，可以到所有的证券公司下载通达信软件，免费的，下载后您会看到登录画面请选择独立行情按登录就可以进入。进到软件分析画面，请选择输入ENE回车就可以看到3条线，原参数是25,6,6.必须改成10,11,9.参数是按照我国股市的涨跌幅限制设定。有的朋友问如何调回均线，请输入MA2回车就可以回到均线画面，在使用过程中你会发现和以前大家学习的知识完全相反，放量上涨到上轨该指标提示的意思是卖出，到下轨不可杀跌而是买入。该指标符合2500只股票里90%以上的股票，包括大盘也符合，基本是围绕在轨道中运行。有的朋友那出10%的个别股问我应该如何操作，我觉得很好有自己的想法，我在节目里讲解的是到上轨时不用马上卖出，（但90%都应该卖）
ENE指标运用和设置 轨道线（ENE）由上轨线(UPWER)和下轨线(LOWER)及中轨线(ENE)组成，轨道线的优势在于其不仅具有趋势轨道的研判分析作用，也可以敏锐的觉察股价运行过程中方向的改变。 一、运用原理及方法： 1.通达信公式： UPPER:(1+M1/100)*MA(CLOSE,N); LOWER:(1-M2/100)*MA(CLOSE,N); ENE:(UPPER+LOWER)/2; 2.当轨道线ENE向下缓慢运行时，如果股价跌穿下轨LOWER后，很快重新 上涨穿越LOWER时，可以买入。 3.当轨道线ENE向上缓慢运行时，如果股价跌至下轨LOWER附近后重新恢 复上涨行情，这时即使没有击穿LOWER也可以买入。 4.当轨道线ENE向上缓慢运行时，如果股价上涨穿越上轨UPWER后，很快 掉头乡下并跌穿上轨UPWER时可以卖出。 5.当轨道线向下缓慢运行时，如果股价涨至上轨UPWER附近后，出现掉头 下跌行情，这时即使股价没有触及上轨UPWER，也可以卖出。 轨道线在平稳震荡的波段行情中能够准确提示出买卖信号，但在股价处于单边上涨或者单边下跌中技巧就完全不一样了。甚至相反。当股市处于急速上涨的过程中，需要在股价向上突破上轨UPWER时买入时机；当股市处于熊市中，在股价处于急速下跌过程中，需要以股价向下跌穿下轨线LOWER时为卖出时机。
二、指标设置： 1、在通达信页面输入英文字母ENE， 按回车键，即会在主图上出现ENE指标线，可以看到ENE 指标由上中下三条线组成。（如下图）
2、将鼠标箭头指向ENE指标线中的任一点，点击鼠标右键，即会出现下图。
底部区域波段操作技法1：瀑布线交易系统 股市投资中常常会出现惯性思维，涨时看涨，跌时看跌的现象比较普遍。大盘暴跌时认为后市下跌空间巨大，慌慌张张的止损割肉。大盘稍有起色时又以为大行情来临，忙着追涨，往往几次追涨杀跌之后，不仅资金严重缩水，心态也遭受沉重打击而一蹶不振。所以，在股市震荡筑底期间，获利的最佳方法就是： 暴跌时要敢于逢低吸纳，反弹上冲时要坚决逢高减磅，也就是要采用波段操作策略瀑布线是波段操作中的一种主要操作方法。 瀑布线是欧美国家九十年代初，广泛应用于金融领域中的判断股价运行趋势的主要分析方法，因此经由汇聚向下发散时呈瀑布状而得名。"瀑布线"属于传统大纯价格趋势线，它的真正名称叫做非线性加权移动平均线，是由六条非线性加权移动平均线组合而成，每条平均线分别代表着不同时间周期的股价成本状况，方便进行对比分析。 瀑布线是一种中线指标，一般用来研究股价的中期走势，与普通均线系统相比较，它具有反应速度快，给出的买卖点明确的特点，并能过滤掉盘中主力震仓洗盘或下跌行情中的小幅反弹，可直观有效地把握住大盘和个股的运动趋势，是目前判断大势和个股股价运行趋势颇为有效的均线系统。 瀑布线的优点还在于其不会类似其它指标那样频繁发出信号，瀑布线的买入或卖出信号出现的不多，如果瀑布线给出了买入或卖出信号，只要按照其应用原则去做，就会取得较好的投资收益。 在趋势明朗的上涨或下跌趋势中，瀑布线能给出明确的买卖点和持仓信号，是把握波段行情的利器，它不仅适用于平衡市的操作，更适用于上涨趋势明显中应用。 瀑布线在平衡市中波段操作的应用技巧： 一、瀑布线买入信号研判： 1、当前股价低于全部的6条瀑布线；
ENE指标用法 (2014-03-28 20:19:56) 转载▼ 分类：经典指标、交易系统 标签： 股票 当轨道线ENE向下缓慢运行时，如果股价跌穿下轨线LOWER后，很快重新上涨并穿越下轨线LOWER时可以买入。当轨道线ENE向上缓慢运行时，如果股价上涨穿越上轨线UPPER后，很快掉头下跌并跌穿上轨线UPPER时可以卖出。 一、指标概述 轨道线（ENE）由上轨线(UPWER)和下轨线(LOWER)及中轨线(ENE)组成，轨道线的优势在于其不仅具有趋势轨道的研判分析作用，也可以敏锐的觉察股价运行过程中方向的改变。 二、计算公式 1.UPPER=(1+M1/100)*收盘价的N日简单移动平均 2.LOWER=(1-M2/100)*收盘价的N日简单移动平均 3.ENE=(UPPER+LOWER)/2 例： N(2,120,25); M1(2,120,6); M2(2,120,6); M3(2,120,12); M4(2,120,12); UPPER:(1+M1/100)*MA(CLOSE,N); LOWER:(1-M2/100)*MA(CLOSE,N); UPPER1:(1+M3/100)*MA(CLOSE,N); LOWER1:(1-M4/100)*MA(CLOSE,N); ENE:(UPPER+LOWER)/2; 同花顺ENE主图指标公式 N:=11;M1:=10;M2:=9; UPPER:(1+M1/100)*MA(CLOSE,N); LOWER:(1-M2/100)*MA(CLOSE,N); ENE:(UPPER+LOWER)/2; 三、应用法则 1.当轨道线ENE向下缓慢运行时，如果股价跌穿下轨LOWER后，很快重新上涨穿越LOWER时，可以买入。(图1)
战法讲解（一）——ENE 已经有越来越多的朋友加到我微信当中，当然其中也有不少的朋友根据战法操作成功有了获利，还有些朋友可能对战法的掌握还不是很熟练。所以从今天开始我会把我的战法还有指标做成一个系列，给大家做个梳理，熟悉的朋友可以巩固复习下，新来的朋友可以系统的做个学习。 昨天已经把指标分享在金融平台软件上了，大家注意下，需要先把自己的软件升级到最新的3.5版本才会有这个指标平台分享的功能。 今天我们开始第一篇内容，来说说ENE。ENE是我一直在课中跟大家提到的指标，跟布林带指标类似，由3条轨道线组成，但轨道的宽度不会像布林带指标出现放大或缩小的变化。 这个指标在实战中，不仅可以敏锐的发现股价运行方向的变化，还可以给我们提供有效的操作信号提示，下面是操作的5条法则。 一、ENE向下运行，股价跌穿下轨，很快重新上涨穿越下轨，视为买入信号。
如易联众（300096），2015年1月15日跌穿ENE下轨，然而在第二天就又上穿上轨，这就是一个很好的买入时机，连续两个涨停板顺利到手也是很不错的。 二、ENE向上运行，股价跌至下轨附近，重新上涨没有跌穿下 轨也可以买入。
宜华地产（000150），2014年10月23日，10月24日以及10月27日这三天股价都在下轨附近运行，但是却没有跌穿下轨，所以说是一个在低位建仓的好时机，后期这一个波段做下来，拿得住的差不多会得到一倍的利润。 三、ENE向上运行，股价穿越上轨，很快掉头向下跌穿上轨， 可以卖出。
如万润科技（002654），在2014年10月9日的时候收盘价站上上轨，第二天高开低走又跌至上轨附近，再看10月13日这天，已经跌至上轨之下了。如此快速的冲高回落也预示着短期走势破坏，这时可以先离场，等待低位再次入场。 四、ENE向下运行，股价涨至上轨附近，出现下跌没碰到上轨， 也可以卖出。
ENE轨道操盘秘籍 ——实战大揭秘 一、指标说明： 轨道线（ENE）由上轨线(UPWER)和下轨线(LOWER)及中轨线(ENE)组成，轨道线的优势在于其不仅具有趋势轨道的研判分析作用，也可以敏锐的觉察股价运行过程中方向的改变。 二、应用法则： 1.当轨道线ENE向下缓慢运行时，如果股价跌穿下轨LOWER后，很快重新上涨穿越LOWER时，可以买入。 2.当轨道线ENE向上缓慢运行时，如果股价跌至下轨LOWER附近后重新恢复上涨行情，这时即使没有击穿LOWER也可以买入。 3.当轨道线ENE向上缓慢运行时，如果股价上涨穿越上轨UPWER后，很快掉头向下并跌穿上轨UPWER时可以卖出。 4.当轨道线向下缓慢运行时，如果股价涨至上轨UPWER附近后，出现掉头下跌行情，这时即使股价没有触及上轨UPWER，也可以卖出。 5.轨道线在平稳震荡的波段行情中能够准确提示出买卖信号，但在股价处于单边上涨或者单边下跌中技巧就完全不一样了。甚至相反。当股市处于急速上涨的过程中，需要在股价向上突破上轨UPWER时买入时机；当股市处于熊市中，在股价处于急速下跌过程中，需要以股价向下跌穿下轨线LOWER时为卖出时机。 三、实战运用 通过以上的描述，投资者大约可以知晓，ENE指标与BOLL(布林线)指标相当的类似，都是属于通道类型的指标。两张的研判法则也十分的类似。那么这个ENE指标究竟好在什么地方呢？根据下面的截图，投资者可以发现，相比BOLL指标而言，ENE指标更加的平滑，
但是平滑的指标并不一定迟钝。 我们都知道，BOLL和ENE的研判法则都有这样一条，在平衡市场中，当K线击穿下轨后迅速回到轨道内，可以视为一个短线的买点。ENE指标在黄色圆圈标示出来的部分，连续的击穿下轨，而BOLL指标只是无限接近于下轨。同样的位置，同样的研判法则。相比较之下，ENE指标在几乎是绝对低点已经发出了短线买入信号，而BOLL指标则必须在轨道转为向上趋势之后，才能按照追涨的法则进行操作，根据益盟操盘手的统计，在相差的15个交易日内，两个指标有9.54%的差距。这仅仅是在指数上，倘若换成个股的话，差距会更被放的更大。 四、超强劲升级 通过上述简单的案例回顾，我们已经发现ENE和BOLL指标都是属于路径型的指标，不仅可以帮助投资者寻找买卖点，同时也可以辅助投资者观察当下所处的趋势。作为一个简单的看盘指标，ENE已经隐隐超越了BOLL指标了。但是，这里存在一个问题，对于投资者原本就熟悉的个股而言，只要再交易时间内盯盘就可以了，但是如何以ENE指标作为选股方式，来进行全市场“无差别”的覆盖式选股呢？ 我们益盟操盘手的研究所根据ENE指标的特性，根据ENE指标最有操作价值的背离功能，对指标进行了独家改造。让投资者可以通过条件选股或者系统预警功能第一时间找到处于背离位置的反弹个股。首先，我们来看一个案例。
1?在FLUENT 里，我们往往想对某一个面或是 点进行观察，来获得其随时间或是距离变化 的情况。下面是步骤： 1，在flue nt 菜单surface 里面定义你所要的点或者面； surface--poi nt--打开网格图，用鼠 标右键选取 reversed k □-Surf ace... ls.T'￡lip... Jrandorm... iter timc/iter solution is canu&rged 设置监测点 2，在solve/monitor/里面选择第一步定义的点或者面， 并在横轴选择为时间 t 或者iterations, 纵轴选择为你关心点或者面的参数（如压力、温度、速度或者湍流强度等） 。3,选择Plot + write J FLUEhT [2d. pbns, sice] ' _____________ ? — _____________________________ : _____________________ - |?|_曲 3d _Qgfine [jdve]刖叫七 砸rfae .0善口la* 上皿 Report 内口阳 Help iter tint Conlros * reversed Flow Ijj+iialijp niters residual,.. reversed Hou ArimatB StstiEtic-. reversed Oou M?sh Moticn.th Force^ Parlkle History Surface 1.,, reuErseil Fluu Execute 匚ornrnands — '/olume… reuerstti Hou C SSF Checks. reuerstrl Flou ltEr3fte…u iter tirit Acotst< $ign 謝s”” —nJ lrer tine/iter f 1SS3 ^Dlution is conuerged 口 FLUENT [2d. pb 昭 ike ： iter reversed flow reversed flow jadric... flow iter * 要观测的点设置完成后，设置监视器，选中 surface hie C^rid Define Solve Adapt ] Display Pict Report Parallel Help time/iter flow in 1 Faces ■ ￡ene... Partition... Points Li n e/ k 巳”