A Modular Client-Server Discrete Event Simulator for Networked Computers?
David Wangerin,Christopher DeCoro,Luis M.Campos,Hugo Coyote and Isaac D.Scherson {dwangeri,cdecoro,lmcampos,coyote,isaac}@https://www.doczj.com/doc/a06414140.html,
Department of Information and Computer Science
University of California,Irvine
Irvine,CA92697-3425,USA
Abstract
A novel simulation framework is described that uses a client-server paradigm combined with a discrete event sim-ulator to allow the simulation modules to be distributed around a centralized core.The framework also simpli?es the creation of new simulations by achieving the goals of being general purpose,easily extensible,modular,and dis-tributed.A prototype of the Client-Server Discrete Event Simulator(CS-DEVS)has been developed as a proof of concept.Two examples are presented to demonstrate the power of the new paradigm and prove the correctness of CS-DEVS.The?rst example is a modeling of the classical bank queuing simulation.The second example models the simulation of a distributed computing system,with complete modules for workload generation,architecture description, and scheduling and load balancing algorithms.
1.Introduction
In the current simulation literature,few simulators are designed to be general purpose enough to serve a wide range of discrete event simulation tasks while at the same time remaining easily extensible and having features such as network transparency and an open and well-de?ned in-terface.To?ll this need,we have developed the concept of the Client-Server Discrete Event Simulator(CS-DEVS)and implemented a preliminary prototype.
CS-DEVS is a general-purpose discrete event simulator framework that allows for distributed computation over a network.It operates from a centralized core that serves to synchronize and facilitate communication between a set of distributed modules(event generators,resource handlers, etc.)in addition to being the discrete event manager.Thus, CS-DEVS is comprised of both a simulator core and a set ?This work was supported in part by NASA-JPL and NASA-GSFC un-der grants number1216595and NAG5-9695respectively of standard runtime libraries for each module.The modules can be either used from a repository of pre-existing mod-ules or written from a template to perform a speci?c task. The methods for communicating through the core are well de?ned,so modules created by different users can seam-lessly and easily interact with each other.CS-DEVS allows dynamic runtime binding between disparate modules.This binding can be between a set of modules on a single ma-chine or on machines located anywhere on the Internet.
It is important to note that modules do not communi-cate directly with each other;rather all communications are directed through the core.The core handles all messages to and from modules,as well as the timing of when mes-sages are sent.Indirect communication is a key concept to CS-DEVS,as modules do not know and do not care about whom they are communicating with.To realize the useful-ness of indirect communication,consider a situation where multiple modules are generating messages of the same type. Since receiving modules do not care about the source of messages,all the messages are handled identically,regard-less of which module generated each message.
CS-DEVS,like all discrete event simulators,handles simulation time in a non-linear fashion.Execution time is not dependent on the length of the simulation time,but is dependent on the number of events that occur in the sim-ulation.A second effect of using discrete events is that modules can submit events before they will actually hap-pen.Since modules are not dependant on a clock,each module is able to execute at maximum possible speed.The core decides when events are triggered and thus synchro-nizes all modules without using an explicit clock or other timer methods.Modules do not act randomly by submit-ting events at unde?ned times,but rather submit events in response to other events.This method gives consistent behavior for all simulations and makes CS-DEVS robust enough to be capable of handling delays in communications that could cause synchronization problems in other styles of simulators.
This paper details the theory and implementation of CS-
DEVS and displays how simulations can take advantage of the distributed nature of CS-DEVS.Two examples are given that both demonstrate the process of developing simulations for the framework and validate the advantageous features of CS-DEVS.
2.Related work
2.1.YADDES
Yaddes is an acronym for Yet Another Distributed Dis-crete Event Simulator[4].The Yaddes system is a tool for constructing discrete event simulations.The principle fea-tures of the Yaddes system are the Yaddes simulation spec-i?cation language and compiler,libraries that support time synchronization methods,a pseudorandom number gener-ator package,and a distributed statistics collection and re-porting package.The Yaddes user prepares a speci?cation of the desired simulation.Yaddes then compiles the speci?-cation into a collection of C language subroutines.These subroutines are then compiled using the C compiler and then linked to a synchronization method library to form a complete program that performs the desired simulation.
The advantage of the Yaddes system over other discrete event simulation packages is that it uses a modeling ap-proach that supports several different synchronization meth-ods.In particular,the synchronization methods currently provided are:sequential(event list driven)simulation,dis-tributed simulation using multiple event lists,conservative (ChandyMisra)distributed simulation,and optimistic(vir-tual time based)distributed simulation.The Yaddes user need not be concerned with the synchronization method used.In fact,every Yaddes speci?cation can be executed using any method merely by linking to the appropriate li-brary.Provided that the speci?cations are coded properly, the results of a simulation are independent of the synchro-nization method used.
2.2.OMNeT++
OMNeT++is a discrete event simulation tool[6].It is primarily designed to simulate computer networks,multi-processors and other distributed systems,but it may be use-ful for modeling other systems too.The goal of the OM-NeT++project is to create a free discrete event simulation system that can be a real alternative to expensive commer-cial products in the same application area.OMNeT++is comprised of several components,including a simulation kernel library,a compiler for the NED topology description language(nedc),utilities(random number seed generation tool,make?le creation tool,etc.),and sample simulations.2.3.SIMSCRIPT II.5
SIMSCRIPT is a commercial discrete event simulator that has been in use for over thirty years.SIMSCRIPT con-tains a full development environment,development tools, and sample applications.The development environment is built around the programming language SIMSCRIPT II.5.The language is a free-form,English-like simula-tion development and modeling language.SIMSCRIPT II.5is designed use with discrete-event and combined dis-crete/continuous simulations.
3.A client-server simulation framework
CS-DEVS uses a client-server approach to simulations. By combining the client-server paradigm with a discrete event simulator,simulation modules can be distributed across a network.If the dependencies between modules can be minimized,modules can execute at peak ef?ciency and take advantage of a distributed computing environment. The simulator core acts as a server to provide a consistent set of functions to many different modules,and modules act as clients that use the server’s functionality to accomplish a task.
3.1.Simulator core
CS-DEVS distinguishes itself from other simulators in that it uses a centralized core to synchronize all commu-nications.Modules never communicate directly with each other but rather send and receive all events through the core. This paradigm allows the core to be?exible enough to han-dle virtually any type of simulation,as the core is focused exclusively on the timing of events and not on the details of any events.The paradigm also allows all modules to be concerned with only the internal operations of the module and not timing and communications details.
The core is deceptively simple in both its operations and its implementation.The core consists of a single events queue,a master clock for the simulation,and a list of event types that should be sent to each module.When events are submitted to the core,they are placed in the events queue according to their execution time.Events are only sent to modules when they are at the front of the queue.By main-taining a time-based priority queue for the events,many synchronization problems are removed,as events can never happen out of order.The master clock is tied to the events queue and can be thought of as a side-effect of the main-tenance of the events queue.Time is only advanced when all events for the current time have been executed and all modules have responded to the current events.Since the core waits for responses from modules before dispatching the next event,synchronization problems can never arise.
Time is not advanced linearly,but jumps to the time of the next event in the queue.The list of event types to be sent to modules is a?lter that ensures that modules only receive the events that affect them.In this way,modules only know about events that are directly related to their operations and a good separation of concerns can be achieved.In addi-tion,the core only waits for responses from modules that can possibly submit new events.
It is important to note that the core does not handle any processing of data for events and does not have pre-determined event types.Any data can be attached to events, but the only data of concern to the core is when the event should occur and what is the type of the event.These two data items are standardized in a particular format for events being submitted to the core,and any additional data con-tained in the event submission is generically considered to be extraneous data for the event.The core never examines the extraneous data and thus the data cannot affect the tim-ing or execution of the core.In addition,the core can handle any type of event without needing any modi?cations or tai-loring to a particular simulation.
3.2.Simulation modules
The interface for modules is also quite simple.Modules register with the core by stating the module name and the types of events it needs to receive.The name is only used for tacking purposes by the core and is not seen by any other modules.After the modules are registered with the core, they submit events to the core and receive events when they are executed.The format of submitted events is the type of event,the relative time of when the event will occur,and any other data that is needed to describe the event.
3.3.Simulation messages
The core and modules communicate through a small set of structured messages.Some messages,such as module registration,are used only for the management of simula-tions.The majority of messages are submit event messages and event occurring messages,which are directly related to the execution of a simulation.The submit event message has the format of the event type,the relative time of when the event will occur,and any other data for the event.The event occurring message has the format of the type of event, the current time(in absolute time),and the other data that is attached to the event.All other events have a format that is abstracted through the programmer’s interface to the mod-ule.The exact format of all messages is detailed in A Gen-eral Purpose Discrete Event Simulator[1]
All modules communicate with the core through TCP/IP network connections.Modules can be located on either the same computer as the core or on different computers
at-
Figure1.An overview of the layout of the sim-
ulator core and modules
tached to a network.The passing of messages over the net-work is handled by the programmer’s interface to modules. Since modules do not need to be on the same computer as the core,and the core does not need to be customized to spe-ci?c simulations,modules can be independently developed by different programmers at different locations and still in-teract seamlessly.
3.4.Simulation control?ow
Many synchronization problems can arise in simulations when modules respond at different speeds and thus have events occur at different times.CS-DEVS overcomes these problems through the use of relative time and a carefully crafted control?ow.
3.5.Relative time versus absolute time
A key concept to the core is that all modules work by relative time and not absolute time.The time?eld of events submitted to the core is in the format of how many time units in the future the event will happen.This prevents any modules from scheduling events in the past,and thus roll-backs are not necessary.
At?rst,this handling of time may seem to be a limitation of the core rather than a feature,but closer examination will reveal than any type of simulation can be handled within this framework.In simulations,no actions are completely random.All actions are determined either independently of other actions or are determined in response to another ac-tion.For consistency,these two types of actions will be re-
ferred to as independent events and reactive events,respec-tively.An example of an independent event would be a sim-ulation of computer hardware faults where a fault will occur every two to ten seconds.The timing of faults does not de-pend on what is happening in the hardware,and thus the timing of all faults can be determined independently from any other events occurring in the simulation.In fact,within the framework of CS-DEVS,all faults could even be deter-mined at the start of a simulation and all fault events could be submitted at once.An example of a reactive event would be a simulation of a computer user where the user performs an action within either one second or one minute of a com-puter action.Whenever a computer action is executed,the user module will decide if the user will react within one sec-ond or one minute,and submit an event accordingly.Note that even though the user is acting in a fashion that may seem random(the choice between reacting in one second or one minute could be data independent),the exact response can be determined at the speci?c time of the computer ac-tion.
3.6.Simulation?ow
The control?ow of the simulator ensures that no mod-ules can become unsynchronized with the timing of the sim-ulation.Since all modules work in relative time to the cur-rent simulation time,the main concern of the control?ow is ensuring that modules respond in a synchronized fashion.
Simulations begin by the core issuing a message that a simulation is going to begin.All modules then submit a list of initial events or no events.The simulation will not begin until all modules have responded.Once all initial events are entered,the event queue is checked for the?rst event. The master clock is updated to the time of the?rst event and the event is sent to all modules that need to receive the event.All modules that receive the event will either submit new events or no events.When all modules that received the event have responded,the core once again checks the event queue for the next event,updates the master clock, and sends out the events to any modules that need the event. This process continues until all events have been processed (or the core is interrupted by a user).
By waiting for all modules to respond before advancing to the next event,there is no possibility of any event being scheduled at an incorrect time.It also alleviates any prob-lems related to network latency or slow computers needing extra time to compute events.Since events are only sent to modules that need the events,the overhead of waiting for module responses is reduced to a minimum.4Simulation of a bank
A standard example often used in literature on simulation is the modeling of daily operations of a bank,with multi-ple tellers serving multiple customers from one or multiple lines.We use this common example to provide a simple in-troduction to the process of developing CS-DEVS modules.
The simulated bank,like any real bank,has a set of cus-tomers that arrive and wish to perform certain tasks,such as deposits,withdrawals and money transfers.When a cus-tomer arrives at the bank,he or she will enter a line.If mul-tiple lines are available,the customer will choose to enter the shortest line.Once in a line,the customer will patiently wait until they are in the front of the line,at which time they will be sent to a teller to handle their business.The teller will complete the customer’s tasks in a?nite amount of time,and once the tasks are completed,the customer will leave,the teller will service another customer,and so on for the rest of the banking day.
The underlying purpose of the bank simulation is to al-low a user to test the effectiveness of various queuing and scheduling schemes.These include:a single?rst-in,?rst-out line for all tellers(as is most common in a real-world bank),an individual line for each teller(similar to the lines often seen in a supermarket)and various other systems,in-cluding dynamically re-prioritized lines and scheduling sys-tems without the?rst-in,?rst-out restriction.
This section describes how this general idea of a bank simulation maps onto the speci?c set of functionality pro-vided by CS-DEVS.Speci?cally,this involves describing each of the modules in the system,the events created and re-ceived by each module,and the response each module will perform given a particular event.
4.1Bank simulation modules
The bank simulation is divided into four modules:the Customers and Tellers,the Bank Line,and the Bank Audi-tor.The Customers module will produce a set of customers that will arrive at the bank at certain intervals to carry out their business.Once a customer enters the bank,the Bank Line module will assign the customer to a particular line, maintain the queue of customers in each line,and assign customers to tellers when tellers are available.The Tellers module will manage the servicing of each customer and de-termine how long each teller service will take.Monitoring all of this activity is the Bank Auditor module.It tracks the statistics regarding the bank and produces a report of items including average customer wait time,average line length, and utilization of tellers.
4.1.1Customers
The Customers module is charged with the responsibility of determining when customers will arrive at the bank.The individual algorithm for determining this is internal to the module.In our speci?c example,the Customers module will be given a distribution range for the total number of customers in a given bank day,and a distribution range for the length of task each customer will need performed. These distributions may be speci?ed as either uniformly distributed across the range,or normally distributed around a mean value.
In this way,the details of the customer’s business is ab-stracted from the rest of the bank simulation,allowing the simulation to focus on its main goal of testing different scheduling systems.While the customer may have a deposit or withdrawal,the Customers module will abstract this by assigning a speci?c time to the individual customer.
Since the arrival of customers is not dependant on any events that occur within the bank,the Customers module will generate and submit all customers at the beginning of the simulation.The core will manage when the cus-tomers are passed to the Bank Line module.Even though it will appear that the Customers module is active through-out the simulation(since customers will appear at the bank throughout the simulated day),it is only needed at the start of the simulation and only needs to make one large commu-nication to the core.
The only type of event generated by the Customers mod-ule is the Customer Arrival event.The Customers module does not respond to any events,so it does not need to listen for any events.
4.1.2Bank line
The most variety is seen in the Bank Line module.This module has a large set of different algorithms that allows the user of the simulation to experiment with different schedul-ing schemes.In this speci?c simulation,the Bank Line module has three different algorithms:a single line algo-rithm,a multiple independent line algorithm,and a dynamic priority-based line algorithm.
When a Customer Arrival event indicates that a new cus-tomer has entered into the bank,the Bank Line will direct that customer to the appropriate queue.Which queue,and to which position in that queue,is determined by the schedul-ing algorithm.
The single-line algorithm is the simplest scheduling scheme.All customers enter the back of a single line,and all customers are dispatched to tellers from the front of the line.Customers may not change positions in the line,and must wait in a?rst-in,?rst-out fashion.This scheme is the one most often used in real banks.
In contrast to the single-line algorithm,the multiple-independent-line algorithm has one line for each active teller at the bank.Each individual line operates under the same rules as the single-line algorithm and thus acts as a FIFO queue.When a new customer enters the bank,the Bank Line module will place the customer in the shortest available line.If a teller becomes inactive and there are cus-tomers in that teller’s line,the customers will be distributed to the remaining lines as through they were new customers. This scheme is not often seen in real banks,but is com-monly used in supermarkets and fast food restaurants.
Like the single-line algorithm,the dynamic priority-based-line algorithm uses a single line,but does not oper-ate in a?rst-in,?rst-out fashion.The algorithm determines when a customer will be serviced based upon the length of the transactions the customer wants to perform and can change customers’positions in the line at any time.Cus-tomers with the shortest transaction time will be placed at the front of the line.Further,when a customer has waited in the line for an extended period of time,the algorithm in-creases the customer’s priority,such that that customer will preempt other customers with lower priority.This system would be unacceptable for a line at a bank,but is often used in telephone service systems(where the line is not visible to the customers).
When the Bank Line module is informed by the Tellers module,through a Teller Available event,that a particular teller is available to service a customer,the Bank Line re-sponds by removing the appropriate customer from the line and sending that customer over to the teller,indicated by the Send To Teller event.
4.1.3Tellers
The Tellers module manages the availability of tellers and the amount of time each teller will take to service a cus-tomer.All tellers are considered equal in their working ef-?ciency and the number of tellers present during any day does not change.
The Tellers module will initially submit a Teller Avail-able event for each teller that is able to service a customer. The Bank Line module assigns customers to tellers through Send To Teller events.When a customer is sent to a teller, the customer is serviced for an amount of time as speci?ed by the customer,and then a Teller Available event is issued to indicate that the teller is ready for another customer. 4.1.4Bank auditor
The Bank Auditor module collects statistics about the per-formance of the simulated bank.It listens to all events and tracks the actions of customers and tellers.Whenever an event occurs,the Bank Auditor module updates its statistics on the average customer wait time,average line length,and
utilization of tellers.The Bank Auditor module is,for all intents and purposes,invisible to all other modules.It does not generate any events and listens to all events.
4.2Bank simulation events
The communication between each module is performed using a set of user-de?ned events.These events serve both functional and informational purposes.Functional events, such as Send To Teller perform a speci?c task upon the data, and trigger speci?c changes in modules other than their https://www.doczj.com/doc/a06414140.html,rmational events,on the other hand,serve to notify another module of a speci?c occurrence,which can then be used for statistics tracking,such as the Customer Arrival event.
4.2.1Bank-open Event
This event is sent at the start of a simulation by the Tellers module.It will inform the Bank Line of the current number of tellers,and serve to allow the simulation to be restarted.
4.2.2Customer-arrival Event
Whenever a customer enters the bank,the Customers mod-ule sends a Customer Arrival event.This event contains a customer record that contains a customer identi?cation number,the arrival time of the customer,and the duration of the customer’s particular tasks.This record will be passed around the simulation,stored during the course of the cus-tomer’s time at the bank,and used to compute statistics once that customer leaves.
4.2.3Teller-available Event
Once customers arrive at the bank,they expect to be ser-viced by tellers.To indicate that a teller is ready,the Tellers module will submit a Teller Available message,which will indicate the number of the particular teller.The Bank Line will receive this message,and when the lines are non-empty, use this information to determine which customer will be sent to which teller.
4.2.4Send-to-teller Event
After the Tellers module has sent a Teller Available event, the Bank Line module responds by assigning a customer to a particular teller,using the Send To Teller event.This event will contain the number of the teller to which the customer is being sent,as well as the customer record submitted in the Customer Arrival event(section
4.2.2)
Figure2.The?ow of messages between mod-
ules
4.3Bank simulation control?ow
Step1:Simulation starts when the Tellers module submits
a Bank Open event,containing the number of tellers
available,and indicating that the bank is open for busi-ness.
Step2:Now that the bank is open,the customers begin to arrive,as the Customers module generates customer records,and submits a set of Customer Arrival events. Step3:Once the customers arrive at the bank,the Bank Line module receives the Customer Arrival events,and adds the customers to the line(or lines)according to the pre-assigned scheduling algorithm.Additionally, tellers indicate their availability,through Teller Avail-able events.
Step4:If tellers are currently available,the Bank Line module will use its scheduling algorithm to select an appropriate customer and teller,and send the customer over to that teller,indicated with a Send To Teller event.
Step5:After the customer proceeds to the teller,the teller will help that customer with their business,and once that business is complete,the customer will leave the bank and the teller will again become available.The simulation indicates this when the Tellers module sub-mits a Teller Available event.
Step6:As long as more customers arrive at the bank,the simulation repeats Step3through Step5.At the end of the banking day,once no more customers arrive at the bank,the bank closes,and the simulation terminates.
5Distributed computing simulation While the simulation of a bank is a common textbook example of discrete-event simulation,a more practical use of CS-DEVS,and indeed one of the main goals for the simulator,is the simulation of distributed computing algo-rithms,speci?cally for distributed and multi-computer op-erating systems.The simulation needs to accurately model the working of a computer network,either through an inter-processor network or inter-computer network,the schedul-ing and load balancing algorithms for each processor and the entire network,and the types of programs being run on the computer network.
5.1Distributed computing modules
The simulation contains three distinct modules:the ar-chitecture module,which handles all details of the inner workings of processors and memory systems,the sched-uler module,which contains the scheduling and load bal-ancing algorithms,and the workload module,which gener-ates models of programs to be run on the computer system.
By separating the modules into these three groups,the simulation can be used to test either the effectiveness of scheduling algorithms,the performance of computer pro-cessors and networks,or the execution of various types of programs on a multiprocessor system.
5.1.1Architecture
The architecture module contains a representation of the number and type of processors used and the network con-necting the processors.The speci?c details of the archi-tecture implementation are abstracted by the module,and made irrelevant to other modules.An architecture may be speci?ed as a shared-bus multiprocessor system or a cluster system,and still export the same interface to the rest of the simulation.
The Architecture module handles all details of tasks be-ing sent to processors,tasks being processed,and tasks be-ing removed from processors.When a task is assigned to a processor,a start-task event is sent to the Architecture mod-ule.The module then processes the task until either the task is completed or the end of a time slice occurs.A task is removed from a processor through either a task-complete event or a time-slice-end event.
Details of inter-processor communications are also ab-stracted through the Architecture module.Any transmis-sion of data that does not involve moving a task is handled through the data-transfer events and data-transfer-complete events.
To describe the inter-connection networks and processor computing power,two different models can be used.One model is a high level description of an architecture with only four parameters and the other model is a low level descrip-tion with many more details and settings.
The high level model is a description called LogP[3][2]. The description contains four https://www.doczj.com/doc/a06414140.html,tency is the time required to send data between any two nodes.Over-head is the processing time associated with setting up to send and receive data.Gap is the minimum wait time be-tween sending messages.P is the relative processing speed of each processor.All connections and all processors are considered to be identical.
The low level model has descriptions for all network connections and all processors.The network is represented with an adjacency matrix.Each entry in the matrix is a value for the connection speed.Note that with an adjacency matrix,each node can have different connection speeds for each incoming and outgoing connection.Each processor has a value associated with it that indicates its processing speed.
5.1.2Scheduler
It is the responsibility of the scheduler module to both schedule tasks to run on particular processors and to sched-ule data transfers between processors.When the scheduler receives a task-arrival event from the Workload module,the scheduler must determine which processors are available and how and where the task should be scheduled to run. Additionally,the scheduler must determine from the infor-mation in the task-arrival event if the task has any data de-pendencies from previous tasks,and if so,it must initiate a data transfer,and cannot schedule that process to run until that data transfer is complete.
5.1.3Workload
Whereas the scheduler module is charged with the respon-sibility of scheduling tasks,it is the workload module itself that generates those tasks.The workload is also responsi-ble for assigning tasks into separate jobs,if applicable.This may be useful for certain scheduling system,such as gang scheduling,which attempts to run all tasks from a particular job simultaneously.
To indicate the arrival of a job or a task to the system, the workload module uses the job-arrival and task-arrival messages.Each of these messages contains an identi?er of the particular job or task.The task-arrival message also contains a Task object.This task object contains the length of the task,which is used in the simulation to determine how much time is remaining for that particular task to run. The Task object also indicates data dependencies between this task and other tasks,which are identi?ed with their task identi?ers.It is then the responsibility of the Scheduler,not
the Workload,to determine if a particular task will require a data transfer to obtain its required data.
Once the scheduler has indicated that a task is complete by sending the task-complete event,the workload will deter-mine if another task is generated,and will send out another task-arrival message,if appropriate.The Scheduler itself is abstracted from the details of the workload speci?cation-the Workload module itself handles the details of task cre-ation and communication.The scheduler is only required to obtain the information from the workload and act appropri-ately.
For the current implementation,the workload is rep-resented as a data-dependency graph,represented in the SHARPE format[5]for task graphs.However,the simula-tion framework is not speci?c to any particular representa-tion.For the generation of SHARPE tasks graphs,we have developed a synthetic workload generator,which given a set of workload characteristics,will produce an appropriate graph.
5.2Distributed computing events
5.2.1System-start event
The system start event is sent by the architecture to signal the start of the simulation.It contains necessary information about the architecture,including the LogP characteristics. This event is also used to allow the system to restart.
5.2.2Job-arrival event
A job-arrival event is sent by the Workload module to the Scheduler,and indicates the start of a job.A job is an entity that is made up of smaller tasks,and is used as a grouping for those tasks.
5.2.3Task-arrival event
Once the Workload module has sent a job-arrival event,it will then send task-arrival events for each task within the job,as they are ready to execute.This event will contain a task object,which will be stored by the scheduler,and con-tains an identi?er of the task,the length of the task,and an array of data dependencies.This array contains the identi-?cation number of each previous task on which the current task depends.
5.2.4Start-task event
In order for the Scheduler to indicate to the Architecture that it wishes to start a task,the Scheduler sends the start-task message.This will provide a speci?c Task object,and will identify the processor on which to run.5.2.5Time-slice-end event
After the Architecture has received a start-tasks message,it will run that task on the indicated processor for a given time quantum,after which time the processor will be interrupted, and the Scheduler will be informed that the time slice has ended.This time-slice-end message will contain the inter-rupting processor and the interrupted task.The Scheduler then has the opportunity to either reschedule the interrupted task,or to run another task in its place.
The Time Slice End event is one of two events that ad-vances time,along with the data-transfer-complete event. All other events occur in zero time.The Architecture mod-ule will schedule a time-slice-end event after the processor has directed it to start a task.Once all other events for the current simulation time have been processed,the simulator core will relay the time-slice-end event to all listening mod-ules and increase the simulation time accordingly.
5.2.6Task-complete event
Eventually,as tasks are run,interrupted,and rescheduled, all tasks will come to completion.When this happens, the Scheduler indicates this with the task-complete event, which contains the identi?cation number of the completed task.This event will be received by the Workload,which will then determine which additional tasks,if any,are to be started.The Workload then sends additional task-arrival events,and the process repeats itself.
5.2.7Data-transfer event
When a system has multiple processors,it is possible that the processors may not have a uni?ed memory architec-ture.In this case,the distributed operating system(rep-resented by the Scheduler module)must ensure that task data is properly transferred to newly arriving tasks,when required.When the Scheduler has received a task-arrival message,and it determines that the new task will be run-ning on a different processor than the tasks on which it is dependant,the Scheduler must then transfer data from those processors to the current processor.This event is sent to the Architecture module,and will contain the source and desti-nation processors of the data transfer operation.
5.2.8Data-transfer-complete event
Once the Scheduler has requested a data-transfer opera-tion,the Architecture must eventually respond with a data-transfer-complete event.The Architecture will use the LogP model to determine when the data transfer could be per-formed,and the time at which it would be complete,and schedules this event to occur at that time.As noted previ-ously,this event and the time-slice-end event are the only
events that advance time.The data-transfer-complete event will contain the same information as the data-transfer event, including the source and destination processors of the data transfer.
5.3Distributed computing simulation control
?ow
Figure3.The?ow of messages between mod-
ules
Step1:The Architecture module sends a system-start event to all other modules
Step2:The workload module sends the initial job-arrival and task-arrival events.
Step3:After receiving the task arrivals,the Scheduler must then determine if the tasks have a data dependency,and schedule a data transfer,if necessary.
Step4:If there are no dependencies,the system schedules the tasks to run on the?rst available processor,which is indicated by a time-slice-end message,by sending a start-task event to the Architecture module.
Step5:If the scheduler was forced to resolve a data de-pendency,the tasks cannot be run until the particular data transfer is complete,in which case the task can be scheduled.
Step6:After a task is scheduled,it will eventually be inter-rupted or terminated,which the architecture indicates to the scheduler via the time-slice-end event.
Step7:If the task has completed,the scheduler indicates this by sending a task-completed event.Step8:Given the task-completed event,the workload will determine if other tasks are spawned,and if so,sends additional task-arrival events.
Step9:The simulation repeats Step3through Step8until the entire workload has been completed.
6Conclusions
The client-server paradigm is easily compatible with dis-crete event simulators,since all events can be categorized as either independent or reactive events.If a simulation con-tains a large number of independent events,a simulation can bene?t from the client-server architecture,because there are few dependencies between modules,and thus modules can take advantage of the distributed nature of a client-server environment.
The simulation framework is applicable for both of the experimental simulations.The core does not need to be modi?ed in either of the simulations,and the inner work-ings of the modules are developed independently of all other modules.The modules are able to communicate through the core and never need direct communication.In addition,all modules are able to execute on machines other than the ma-chine running the core
All of the goals of the simulation framework are accom-plished and proven through the examples.The examples are also distinct enough to demonstrate that the CS-DEVS framework can handle virtually any type of simulation. References
[1]L.M.Campos et al.A General-Purpose Discrete Event Simu-
lator.In Symposium on Performance Evaluation of Computer and Telecommunication Systems,2001.
[2] D.E.Culler,R.M.Karp,D.A.Patterson,A.Sahay,E.E.
Santos,K.E.Schauser,R.Subramonian,and T.von Eicken.
LogP:A Practical Model of Parallel https://www.doczj.com/doc/a06414140.html,muni-cations of the ACM,39(11):78–85,1996.
[3] D.E.Culler,R.M.Karp,D.A.Patterson,A.Sahay,K.E.
Schauser,E.Santos,R.Subramonian,and T.von Eicken.
LogP:Towards a Realistic Model of Parallel Computation.
In Principles Practice of Parallel Programming,pages1–12, 1993.
[4] B.R.Preiss and I.D.MacIntyre.YADDES-Yet Another
Distributed Discrete Event Simulator.Technical report,Dept.
of Electrial and Computer Engineering and Computer Com-munications Networks Group,University of Waterloo,1990.
[5]K.Trivedi et al.Performance and Reliability Analysis of
Computer Systems:An Example-Based Approach Using the SHARPE Software Package.Kluwer Academic Publishers, 1995.
[6] A.Varga.The OMNeT++Discrete Event Simulation System.
In Proceedings of the European Simulation Multiconference (ESM’2001),2001.
电脑网络维护合同 甲方：潍坊启明科技网络服务中心(签章) 乙方：_________________（签章） 2012年__9__月___1___日 电脑网络维护合同书 甲方：潍坊启明科技网络服务中心 乙方： 双方经友好协商达成一致共识，签订此电脑维护合同，具体事项如下：硬件： 一、维护范围及内容： （1）电脑硬件故障维修（电脑主机〈CPU、硬盘、内存、主板、显卡〉、显示器）。 （2）电脑软件故障维修（包括系统安装、系统还原、系统更新、定期检查、常用软件安装）。 （3）局域网故障维修（对现有公司内部局域网络维护、测试、保证内部网络通讯正常）。 （4）指导、协助备份重要数据。（甲方不对乙方数据丢失负责）。
二、维修方式： (1)突发故障的上门维护：在接到乙方的电话或其它通知后，甲方 必须最迟在第三个工作日进行上门维护。 (2)每季度一次定期探访维修系统，对用户的系统进行优化配置，调试好应用软件及相关硬件设备，使系统达到更高使用效率。 三、收费： 1、甲方向乙方提供电脑定期维护，维护期限__年，从2012 年__9_月__1_日至__2013_年___9月__1_日,乙方所需维护电 脑台数是___台,甲方按电脑每年__100_元/台计费；电脑维护 费共：——；针式打印机，喷墨打印机，打印复印扫描一体机 共———台，每年100元/每台，服务期限为___年,共计维修 费用为人民币_______元整；共计所有综合整体费用每年___ 元，大写：————————— 双方签约后，乙方将该合约总金额以现金方式或银行转帐方式一次性支付给甲方。 四、双方责任： （1）甲方在维护期限的工作时间内必须尽职尽责为乙方提供电脑维护项目里的服务内容，乙方要求服务的联系方式为电 话联系或网上留言，乙方发出维护请求后，甲方必须最迟 在第三个工作日内响应服务，如有特殊意外，双方调解处 理。
计划编号：YT-FS-3872-21 2020市场推广年度工作计划模板(完整版) According To The Actual Situation, Through Scientific Prediction, Weighing The Objective Needs And Subjective Possibilities, The Goal To Be Achieved In A Certain Period In The Future Is Put Forward 深思远虑目营心匠 Think Far And See, Work Hard At Heart
2020市场推广年度工作计划模板(完 整版) 备注：该计划书文本主要根据实际情况，通过科学地预测，权衡客观的需要和主观的可能，提出在未来一定时期内所达到的目标以及实现目标的必要途径。文档可根据实际情况进行修改和使用。 1 市场部职能 2 市场部组织架构 3 市场部工作计划 4 市场部xx年销售计划 实行精兵简政、优化销售组织架构 实行严格培训、提升团队作战能力 科学市场调研、督促协助市场销售 协调职能部门、树立良好企业文化 把握市场机会、制定实施销售推广 信息收集反馈、及时修正销售方案 一市场部职能： 市场部直接对销售总经理负责，是企业的灵魂，
其工作职能在生产、销售、服务中的作用十分重要，是销售环节核心的组成部分，作为市场部，重要的工作是协助总经理收集、制订、执行。衡量市场部工作的标准是：销售政策、推广计划是否科学、执行力度是否严谨。 1.市场部作用: 直接对总经理负责，协助总经理进行市场策划、销售计划的制定和实施。 督促销售部对销售计划进行事实。 全面协调各部门工作职能。 是企业的灵魂。 2.市场部工作标准： 准确性 及时性 协调性 规划力 计划性 执行力
计划编号：YT-FS-1634-77 市场部营销推广工作计划 4(完整版) According To The Actual Situation, Through Scientific Prediction, Weighing The Objective Needs And Subjective Possibilities, The Goal To Be Achieved In A Certain Period In The Future Is Put Forward 深思远虑目营心匠 Think Far And See, Work Hard At Heart
市场部营销推广工作计划4(完整版) 备注：该计划书文本主要根据实际情况，通过科学地预测，权衡客观的需要和主观的可能，提出 在未来一定时期内所达到的目标以及实现目标的必要途径。文档可根据实际情况进行修改和使用。 针对市场部的工作职能，我们制订了市场部×× 年工作思路，现在向大家作一个汇报： 一、建立酒店营销公关通讯联络网 今年重点工作之一建立完善的客户档案，对宾客 按签单重点客户，会议接待客户，有发展潜力的客户 等进行分类建档，具体记录客户的所在单位，联系人 姓名，地址，全年消费金额及给该单位的折扣等，建 立与保持同政府机关团体，各企事业单位，商人知名 人士，企业家等重要客户的业务联系，为了巩固老客 户和发展新客户，除了日常定期和不定期对客户进行 销售访问外，在年终岁末或重大节假日及客户的生日， 通过电话、发送信息等平台为客户送去我们的祝福。 今年计划在适当时期召开次大型客户答谢联络会，以
加强与客户的感情交流，听取客户意见。 二、开拓创新，建立灵活的激励营销机制。开拓市场，争取客源 今年市场部将配合酒店整体新的营销体制，重新制订完善××年市场市场部销售任务计划及业绩考核治理实施细则，提高营销代表的工资待遇，激发、调动营销人员的积极性。营销代表实行工作日记志，每工作日必须完成拜访两户新客户，三户老客户，四个联络电话的二、三、四工作步骤，以月度营销任务完成情况及工作日记志综合考核营销代表。督促营销代表，通过各种方式争取团体和散客客户，稳定老客户，发展新客户，并在拜访中及时了解收集宾客意见及建议，反馈给有关部门及总经理室。 强调团队精神，将部门经理及营销代表的工薪发放与整个部门总任务相结合，强调互相合作，互相帮助，营造一个和谐、积极的工作团体。 三、热情接待，服务周到 接待团体、会议、客户，要做到全程跟踪服务，
Making a comprehensive plan from the target requirements and content, and carrying out activities to complete a certain item, are the guarantee of smooth implementation.营销年度工作计划正式版
营销年度工作计划正式版 下载提示：此计划资料适用于对某个事项从目标要求、工作内容、方式方法及工作步骤等做出全面、 具体而又明确安排的计划类文书，目的为完成某事项而进行的活动而制定，是能否顺利和成功实施的 重要保障和依据。文档可以直接使用，也可根据实际需要修订后使用。 1. 长远目标：20xx年实现行业品牌效应 2. 1-2年目标：打好营销内部基础，抓好产品品质，树立好辉达品牌在消费者心中的形象，调研市场需求，开发设计新产品，不断的完善产品链，推动好企业正式运行品牌渠道销售进程。 3. 20xx年度目标： ①. 业绩目标 理想目标：0.7个亿基本目标：0.5亿 产品种类：电子人体秤电子厨房秤
电子厨房秤电子营养秤电子口袋秤机械人体秤机械厨房秤 ②. 营销团队：6-8人 ③. 市场覆盖面：国内范围发展、一线城市、二线城市为主拓展到地级市国外市场主要以欧美亚洲市场为主. ④. 市场占有率：3%-5% ⑤. 其他目标： 外贸销售目标：做电子衡器的专业贸易公司 渠道销售目标：做国内家用电子秤行业领军者 构建正常运转的营销管理体制; 组建优秀的营销团队; 一、市场调研与分析
(一)经营环境 1. 国际经营环境 整个国际环境经济萎靡，大部分垮地区、垮国界的投资在衰退。小型家用电子产品国际贸易有上升趋势 2. 国内经营环境 一线城市不断成熟，二线城市不断崛起，国家经济重点开发区快速发展 (二) 市场需求 1. 行业环境：随着人们生活的稳定，品味的提高，消费者对美的追求，对人体秤也越来越受女性朋友的追捧，随着人们健康的要求也越来越高，厨房秤也随之走进千家万户。市场需求在不断提高，行业处于快速发展期。
市场推广年度工作计划范文 推广年度时间：20**0月——20**2月31日 年度销售任务：6125万 年度推广费用：340万 策略阐述： 根据市场现状及竞争对手的状况来看，照明行业走到今天，经验主义、行业瓶颈等已经影响整个照明行业的发展，整个行业的抄袭之风成灾，照明营销走到今天已经失去了创新、发展的激情，在世界营销大变革 的时代，完全套用行业内多年前的成功模式已经失去意义。 · 在市场推广的整体区域规划中我们将采用集中资源、局部突破并最 后影响全国市场形成特有的安尚营销模式，利用有限的资源集中投放 在少数几个重点市场，在短时间内占据区域市场份额的前列，再将区 域市场的营销模式总结分析，快速在全国实行推广，完成全国市场的 战略布局； · 在市场推广的产品规划中，我们拟采用单个特色化产品、优势（成 本优势或技术优势等）产品的重点推广带动整个产品群的提升，确定 其在照明行业某一领域的补缺和领导地位，进而通过一系列的市场运作，影响、带动其它相关产品群的提升； · 在市场推广的策略组合中，我们拟希望通过突破传统的照明行业推 广手段，选择性的导入其它行业的成功推广模式，以品牌主题推广影 响市场推广，以市场推广加速品牌影响，并根据不同时期内市场情况 通过组织数次“海陆空”式的纵深立体化战役推广，分步骤的实现营 销推广目标。 · 在推广的目标受众选择上我们前期主要集中在行业内的专业人士以 及渠道经销商、工程建筑商、承包商等，逐步建立在行业内的专业品
牌地位，再根据流通类产品的推出，再将推广的重心向目标消费群体转移，完成专业领域的强势品牌向大众化品牌的转化。 · 推行体验营销，围绕核心竞争力以服务为舞台、以商品为道具、以消费者为中心，创造、设计一系列能够使消费者参与、值得消费者回忆的活动（路演）模式，让消费者亲自体验安尚照明带来的利益； · 以行业内、跨行业、渠道内、渠道外的联合促销为主要推广方式，化的利用传播资源，形成一个立体的装饰、建筑消费整体。 【一、推广目标】 · 销售任务目标：完成年度销售任务6125万； · 广告宣传目标：在推广年度内确立行业内专业品牌地位，在行业内具有一定知名度； · 渠道目标：完成全国布点任务，在全国主要一、二类市场建立销售网点；并在推广年度末在全国范围内建立100家以上专卖店；全国隐性渠道体系的建立。 · 管理目标：在推广年度内建立完善的推广策划、执行、反馈、评估体系； · 产品目标：完善产品线；确立在市场竞争力的核心产品群。 【二、推广目标受众】 · 推荐作用类：设计院、监理公司、建委； · 目标客户类：建设单位、房地产公司、装修公司等 · 渠道成员：经销商、导购人员、员工等 【三、重点推广区域】 全国发达地级市以上市场
2020市场部年度营销工作计划 导读：本文是关于2020市场部年度营销工作计划，希望能帮助到您！ 伴随着万达购物广场的落成，市场部始终坚信“公司的战略是清晰的，定位是准确的，决策是正确的”，随着发展适时调整适合现阶段中国市场发展的商业营销模式，快速确定了最合适的营销理念。职务分析，万达购物广场市场部，主要负责购物广场战略目标的规划，对市场“商场如战场”发展趋势做出预测，对目标客户的需求做出判断，对竞争对手和潜在竞争对手的策略做出分析。包括广告宣传、公关活动、促销活动、讲座与展会，以及网上资料、印刷资料、音像资料的制作。正常来讲他们并不大量接触零散的客户，而是紧盯住一个目标客户“群体”去做工作，去激发他们的潜在需求。因此，在下一年的工作规划中，将针对以下几点工作来进行。 一、主要竞争对手分析 就现阶段而言，我市各大购物广场的销售额主要是依靠制造各种形式的活动，让利于消费者、吸引消费者，从而达到引导消费者消费、提升自身销售额的目的。作为我们而言，市场的分析是重中之重，如何把握市场发展趋势，在众多商家、众多活动中脱颖而出，吸引更多的消费者，创造更多价值，在招数上出奇制胜非常关键。也是我们在 2020 年的工作重点。 去年我们着重对全国的商业模式进行了考察，大连万达模式对我们深受启发我们也通过网络了解和电话咨询等进一步了解到万达的整体策划也不是他们自己搞的完全是依赖大连的展览公司。整体策划是以 4t 商业营销模式为基础以休闲、体验、互动、娱乐四大元素组成，直击网络购物的致命弱点，他们在策划方案中融入各种展览旅游文化教育等形成互位交叉
和资源共享购物广场在营销策划上逐渐向以服务为轴心的商业综合体转化;将原来的美陈的投资大量压缩全部采用租赁的模式。他们的策划方案深受启发很值得我们学习和借鉴。这一点我们市场部已经开始学习和贯彻《商业 4t 营销理论》。把我们原来的供应商体系重新做了梳理，引进大连几家专业从事展览器材及展品租赁的供应商，这样我们将大大节省了 2020 年商业美陈的投入。并随时关注大连万达的发展动向，即时做出调整。购物广场的壮大，离不开新老顾客不间断的物质资助。不断把潜在顾客变为顾客，把顾客变为老顾客、忠实顾客，也将是购物广场发展的必由之路。因此，发展会员，推行会员卡，同时不断通过相关活动把顾客提升为沈阳大悦城家族的一分子、一部分，应是2020年战略规划之一，而会员卡也将在下一年的各个活动中具体体现和运用起来。 二、广告公关 我们做广告的目的，就是第一在消费者心目中树立良好、牢固的企业形象，提高美誉度和认同度;其二就是借助广告媒体对商业信息进行有效传递，提升实效性。两相结合，才是相对完善的广告宣传。 长期以来，我们的广告媒体主要是以电视字幕广告为主流媒体，从实效性来看，的确具有一定的效果，但是作为主流媒体，欠缺的是无法将形象树立在市民心中，而对于现代广告营销而言，电视字幕、短信等广告媒体也只是起到发布信息的作用，并没有完全发挥出“广告形象宣传”的作用。在 2020 年，首要的任务则是根据以往收集来的各广告公司、广告媒体进行深入分析，确定出着实适合我们企业的主流媒体作为宣传平台，并根据该媒体特点制定长期宣传战略，使其切实为我们服务，达到真正广告宣传的目的。其次，在依托主流媒体进行形象宣传的同时，尽可能多地通过各种方式增加社会影响力，如制造新闻看点、发展大型文化主题巡展等
理想CR1630一体机维修资料 （1）操作程序 在执行测试功能程序，维修技术员能检测每一个电器元件的状态。1．进入测试功能 同时按下?和?两键打开电源开关。如果进入测试功能，机器的印刷数量显示板上显示系统ROM版本。2．检测部件操作，可用操作见选择测试编号。{例}选择测试号NO。36（传感器状态）按START见开始测试，在按START停止测试。3．操作记忆开关（测试功能200—218） 进入测试功能并选择记忆开关号并按START键。{例}选择记忆开关号201选择201并按START 用?或?键选择设定直。{例}选择E为设定植，按?键使E在第一格内闪烁。按STOP 以便重新选择设定。按ALL RESET见1秒钟。注意：测试功能号98使所有记忆开关选择复为‘0’。（2）测试项目及操作 1．传感器/开关测试 有两种不同方式的叫声告知目前状态。检测到 0.1秒间隔的叫声位检测到 0.5秒间隔的叫声序号检测元件检测内容 01 纸检测传感器检测反射光02 上限开关光路被阻挡03 下限开关光路被阻挡06 纸传感光路被阻挡08 位置A传感器光路被阻挡09 夹板A位置传感器光路被阻挡 10 夹板B位置传感器光路被阻挡12 切刀开关开关不被按下14 版纸传感器检测反射光 15 版纸位置传感器检测反射光17 油墨盒传感器光路被阻挡18 滚筒装入传感器光路被阻挡19 出纸传感器检测反射光21 ADF到为传感器光路被阻挡22 垂直中心传感器光路被阻挡23 版纸用完传感器光路被阻挡24 版纸张紧板传感器光路被阻挡25 废版纸压缩传感器光路被阻挡26 废版纸满传感器光路被阻挡27 卸版单元装置开关开关被按下 28 卸版传感器光路被阻挡29 制版单元传感器开关被按下34 原稿位置传感器光路被阻挡36 原稿输入传感器检测反射光37 油墨传感器检测油墨38 油墨溢出传感器检测油墨 41 原稿到位传感器当可选件安装时 2．电机/电磁铁测试 用START见作开/关控制 序号检测元件 56 进搞电磁铁57 写入步进电机向后200步58 写入步见电机向前200步59 主电机10转/分钟60 主电机15转/分钟61 主电机30转/分钟62 可变速主电机运转（用印刷速度键控制）63 分离和负压风扇64 写入步进电机向前400步65 写入步进电机向前300步66 装载离合器67 进纸离合器68 压力电磁铁 69 70 夹板复位71 卸版电机73 夹板电机74 扫描电机向前运转（用缩小键来控制）77 打印头控制信号79 扫描器发光二极管阵列亮84 进纸步进电机向后转89 版纸张紧板电磁铁 3．内存清除及记数停止等按START键，面版显示正常状态 序号清除项目 90 部分内存清除主板中RAM包含的确定内容，如卡纸，出错等将被初始化。油墨定时器记忆开关及用户功能保留。（在开电同时按ALL RESET键，将做同样操作）92 禁止版纸及印张记数，及磁卡记数信号。版纸记数及印张记数信号无输出，用于维修人员试印而无记数关机后该状态既解除。93 清除内存记数清除内存中的版纸及印张记数不清除油墨定时，卡纸，出错信息，记忆开关及用户功能。97 用户功能数据清除 所有包含在主版中的RAM内容，包括由测试功能200---217设定的记忆开关设定值都被清零。 98 内存清除仅清除用测试功能200---217设定的记忆开关设定植。
市场推广年度工作计划(标准 版) Through the work plan, you can make a plan for future work and work out a detailed plan; the work plan function greatly improves work efficiency. ( 工作计划) 部门：_______________________ 姓名：_______________________ 日期：_______________________ 本文档文字可以自由修改
市场推广年度工作计划(标准版) 导语：通过工作计划，可以对未来工作进行一个规划，制定出详细计划；这样能让工作更有条理性，还能对工作进行全局的管理，可以更好的应对工作中遇到的问题，工作计划功能对提升工作效率有很大提升。 推广年度时间：20**0月——20**2月31日 年度销售任务：6125万 年度推广费用：340万 策略阐述： 根据市场现状及竞争对手的状况来看，照明行业走到今天，经验主义、行业瓶颈等已经影响整个照明行业的发展，整个行业的抄袭之风成灾，照明营销走到今天已经失去了创新、发展的激情，在全球营销大变革的时代，完全套用行业内多年前的成功模式已经失去意义。 ·在市场推广的整体区域规划中我们将采用集中资源、局部突破并最后影响全国市场形成特有的安尚营销模式，利用有限的资源集中投放在少数几个重点市场，在短时间内占据区域市场份
额的前列，再将区域市场的营销模式总结分析，快速在全国进行推广，完成全国市场的战略布局； ·在市场推广的产品规划中，我们拟采用单个特色化产品、优势（成本优势或技术优势等）产品的重点推广带动整个产品群的提升，确定其在照明行业某一领域的补缺和领导地位，进而通过一系列的市场运作，影响、带动其它相关产品群的提升； ·在市场推广的策略组合中，我们拟希望通过突破传统的照明行业推广手段，选择性的导入其它行业的成功推广模式，以品牌主题推广影响市场推广，以市场推广加速品牌影响，并根据不同时期内市场情况通过组织数次“海陆空”式的纵深立体化战役推广，分步骤的实现营销推广目标。 ·在推广的目标受众选择上我们前期主要集中在行业内的专业人士以及渠道经销商、工程建筑商、承包商等，逐步建立在行业内的专业品牌地位，再根据流通类产品的推出，再将推广的重心向目标消费群体转移，完成专业领域的强势品牌向大众化品牌的转化。
一、打印机故障诊断基本方法 1、故障信息提示法 2、直观发现法 3、机器测试诊断法 4、遵循先易后难原则逐个排除法 5、替换法 二、如何提高打印速度及节省墨水量 选择经济模式颜色为灰度打印及高速打印，可以节省更多的墨水，但打印质量却不尽人意，一般在打印样张或打印文本时采用。 尽量节省墨水，巧妙地给墨盒加墨，当某一种颜色用完之后，如有单色图片可以打印，或填充缺色颜色墨水，继续打印。 不要立即更换墨盒，在打印机墨水灯亮之后，还可以打印文本20-30页，打印图片1-3张。 三、打印速度、分辨率与打印效果有何关系
分辨率（Dpi点/英寸）是表示每英寸长度上打印点数的参数值，在打印中相同的机型，DPI设定值越大则打印效果越好，打印速度越慢，墨水用量越大；DPI设定值越小则打印效果越差，打印速度越快，墨水用量越小。在不同打印机设置选择不一样，有些打印机是直接选择打印介质，因为它们是内置参数已确定了。 四、如何更换墨盒 1、自然使用完的墨盒打印机会有红灯或显示器会有互换指示，直接按下相应故障灯的换墨键或在文件属性的应用工具中更换即可； 2、CANON、HP等部分打印机，把上盖打开就可以直接更换墨盒。 3、有专用的更换墨盒键的打印机则按下专用换墨键即可； 4、三个键的打印机则按住进纸键三秒。 5、四个键的打印机则按黑墨键和彩色键分别更换； 6、四个键以上的则要按清除键和黑墨键或彩墨键分别一起进行互换； 7、请具体按照打印机上说明的步骤行互换； 8、不能强行用手推动墨盒装置的小车来更换；
9、维修拆装时用小尺子拨动小车的白杆再移动小车。 10、可利用电脑中“打印首选项”的换墨程序进行换墨。 五、打印头不出墨（俗称堵头）的原因及处理方法 真堵原因： 1、打印间隔时间太长，造成打印头干涸（建议每星期开机打印一张全色文档）。 2、封条未撕开，空气不进入/将黄色封条撕开重装墨盒。 3、经长时间多次清洗打印头测试断线位置一致的/用注射器清喷头/用清洁墨盒清洗喷头。 4、打印头磨损或老化-----需要更换打印头。 5、EPSON机型清洗喷头方法： 轻度堵头：直接用右击打印机，选择“打印首选项-清洗打印头3-5次。
2019 年市场推广工作计划模板 20xx 年公司成立市场部，它是公司探索新管理模式的重大变革。但在经过一年之后，市场部成为鸡肋，嚼之无味，弃之可惜; 市场部除了做了很多看起来似是而非的市场活动，隔靴搔痒的市场推广，就是增加了很多直接或间接的费用，而看起来对市场没什么协助。但在公司领导高层的支持和我们持续地学习中，在后几个月的工作中也探索我们的生存和发展之路，在公司的各项市场活动中，公司资源整合过程中，持续进步。 二、【工作思路】 1、明确工作内容 首先就必须让市场部从围绕营业部转、担当营业内勤的角色中快速转变过来，从事务型的办公室职能里解脱出来，真正赋予市场部战略规划、策略制定、市场调研、产品开发等基本的岗位职能，以消费者需求为中心，根据不同的市场环境，对市场运作实行策划及指导。 2、驻点营销 驻点市场的推行既锻炼、提升市场部人员自身，又贴身服务了一线业务人员，市场部只有提供了这种贴身、顾问、教练式的全程跟踪服务，市场部才能彻底改变一线人员对其的片面看法。（此工作策略需建立在市场部有较宽松及多余的自由支配工作时间及较合理的人员配备条件下展开实施） 市场部驻点必须完成六方面的工作： a、通过全面的调研，发现市场机会点，并针对性地拿出市场提升方案; b搜集竞争品牌产品和活动信息，捕获市场消费需求结合行业发展趋势，提出新产品的开发思路; C、指导市场做好终端标准化建设，推动终端门店健康稳定发展 d、针对性地制定并组织实施促销活动方案，对市场促销、费用及政策使
用情况实行核查与落实，发现情况即时予以上报处理。 e、即时全面宣贯公司政策，提升一线人员的战斗力；制定不同时期的有针对性的员工激励方案，提升员工积极性，进一步为公司提升竞争力； f 、在市场实践中搜集整理亮点案例，重点总结出方法和经验，即时推荐给市场复制; 3 、与营业部强强联合，营运部相互配合促动提升，成立品牌推广小组市场部要在市场一线真正发挥作用，除了调整市场部定位及提升市场部自身服务水平外，还离不开一线部门的支持和配合。如果得不到市场一线的认可和有效执行，即使再好的方案，最终也只能是一纸空文。由市场部和营业部两部门的主管和骨干组成品牌小组，由市场部确定活动企划方案，再由品牌小组成员发表意见，主要对方案提出看法和改进建议，对于需进一步修改完善的方案，由市场部负责调整; 对于会议讨论通过的方案，由总经办最终确认执行，交营业部执行，由品牌小组负责跟踪执行进度和效果。而公司的态度和做法，决定了市场部能否与营业部实现共融和共荣。品牌小组计划主要执行工作： 1.【规范终端门店品牌形象】20xx 年4-5 月份制定家家知连锁门店统一门店形象标准，包括门店陈列规范、音乐播放（不同季度及节日音乐）、家家知统一服务礼仪、家家知终端宣传品使用规范等终端门店统一形象，方便对家家知连锁品牌的统一性实行规范; 2.【门店稽核管理制度】由品牌小组成员及总经办成员组成门店督察小组，建立门店稽查制度，不定期对上述第一条中规范内容实行稽查，稽查结果算入门店店长及责任员工绩效考核中，协助公司建立统一的终端形象和后期品牌形象的管理维护; 品牌小组组成： 组长：市场部经理副组长：营运部总监顾问：副总经理 执行队长：营业部经理组员：门店主管 备注：各项规范制度由整个品牌小组共同协商制定，经总经办批准确定后长期执行，后期门店运营管理中，品牌小组中成员每次对门店实行巡店均为一次稽核过程，稽核内容如上，稽核过程中会根据各项稽核内容对门店店长及
?广场 ?lwf0822 ? ?退出 关注此空间 连云港博亿办公个人博客空间 发烧音响 2011-01-25 11:19 联想-M7020（兄弟DCP-7010）出现“unable to print”的问题探讨机器报错 联想-M7020（兄弟DCP-7010）出现“unable to print”的问题探讨机器报错，出现提示：“unable to printSEE TROBLE SHOOTING AND ROUTINE MAILTENANCE CHAPTER IN USER,S GUIDE”，机器不能打印、复印，只能扫描，无法正常工作。试将其他正常机器上的粉盒、鼓投入故障机器，重新打开电源不再告警提示，故障完全消除。可见，问题出在鼓或粉盒上。但究竟是粉盒问题还是鼓件问题，用替换法做进一步验证。用正常机器上的鼓替换故障机器的鼓，而故障机器上的粉盒仍不变，结果故障提示依旧。此时用故障机原来的鼓件配上正常机器上的粉盒，故障提示消失。显然得出结论粉盒有问题。购买一个新粉盒固然能解决问题，但粉盒价格不菲！能不能考虑修复粉盒呢？该粉盒不含任何计数芯片，完全是一个机械构件，因此一旦找出故障原因也就有机械修复的可能！进一步分析，能正常使用的粉盒是原装粉盒从未充过墨粉，印数充其量也就3千以下，而报错的粉盒已经多次充粉，印数已达2万7千份。看来故障跟充粉及使用期限过长有关。既然曾经多次充粉都能正常使用，估计跟充粉的关系不大。机械构件使用过长后就有可能造成运动部件磨损老化或运动部件缺少润滑而阻力增大。进一步拆下齿轮部件发现齿轮及粉棍轴套内均遭墨粉污染，齿轮轴内润滑脂也遭墨粉污染而变得粘稠。将齿轮和粉棍拆下来，轴及轴套部位擦拭清洁干净后重新涂抹润滑脂（或以少量机油替代），装好后投入机器，开机后故障排除 原文出自: 办公中国(https://www.doczj.com/doc/a06414140.html,/) 详细文章参考： https://www.doczj.com/doc/a06414140.html,/thread-101928-1-1.html ------------------------------------------
市场推广年度工作计划 篇一：市场推广部年度工作计划大全 市场推广部年度工作计划大全 关于市场推广部年度工作计划大全 市场推广部年度工作计划一： 受两方的促销。 ?如建材超市渠道：与渠道共同承担、联合组织店长推荐、单品超低特价等终端促销活动注：此项活动可由区域经销商自行组织终端促销活动，公司可根据情况提供物料支持和费用支持; 2.2.3 、现场推广活动 选择5-6 个重点区域，结合商业照明产品的上市，根据上市产品特性设计一系列的产品特点演示、产品体验环节，配合生动化的终端展示物料，现场设计一新闻点，进行新闻软文、报道炒作。 发布方式：由公司提供活动物料及策划、媒体报道支持，活动区域经销
商承担场地、工商、城管费用以及活动信息发布、人员费用。 2.2.5 、节约中国节能安尚安尚节能系列产品市场推广活动 结合xx 年中国节约年的影响以及世界能源紧张的现状，借力中央电台每天呼吁的节约中国的广告语，在xx 年年底的新产品推出的时候以高端软文、新闻报道、平面广告的等高端媒体的舆论炒作，建立品牌形象，配合对节能产品的终端赠品促销、终端物料宣传，形成一个立体化的推广活动。 2.2.6 、五子登科大派财——福、禄、寿、喜、财 主要针对流通类产品在元旦以后至农历正月15 日期间以刮刮卡的形式为客户派送红包：分别分为福如东海奖、禄厚官高奖、寿比南山奖、喜气洋洋奖、财源滚滚奖分别设置不同金额的红包。 活动开展方式：公司提供策划、广告宣传、广宣物料费用，经销商承担奖品费用; 2.2.7 、日常广宣物料、促销礼品等提供，作为区域性、短期促销物料。 3 、公关活动
3.1 、主要合作媒体：（待定） 3.2 、媒体关系管理 与行业内专业媒体以及相关大众媒体建立良好的合作关系，通过新闻采访，增加企业与客户、见面的机会，将市场上的每一次动作、每一次新产品的推出都能站在更高的高度展现在大众面前; 如：根据产品上市情况以新闻发布的形式邀请部分在行业内有影响力的专业报刊、杂志、网站对新产品进行感受、了解，并以新闻通稿的形式营造短期内的产品上市新闻热点。 3.3 、区域房产活动赞助 赞助类似商业步行街开发商主办的如：招商会、封顶典礼之类的活动，提升区域内客户对品牌的关注度; 3.4 、ansorg 精英俱乐部 目标会员：行业内的设计院设计师、工程师、主管部门领导等等俱乐部形式：定期根据会员的生活喜好，收集相关娱乐、体育情报等资讯精选（如大片评论、放映时间、世界杯看球攻略等），每期定期出版，给会员参考、阅读，作为会员与公司交流的一个平台，并结合 社会时尚主题举行一系列的促销活动（如发放《墨子攻略》首映门票、野外生存大挑战、世界杯竟猜、以精英俱乐部组织中国偏远山村生活体
理想GR速印机维修代码 第一部份：自检功能（用来检测每个电器部件是否正常） [开始测试操作]（同时按下“线条稿/照片”和“制版/印刷”按键，打开电源。）用两种不同的叫声区别当前测试元器件状态是否正常（检测到： 0.1秒间隔的叫声） （未检测到： 0.5秒间隔的叫声）1）[传感器/开关测试]. 2 纸尺寸传感器. 反射光检测 3 限传感器. 光路被挡 4 进纸压力开关.开关打开 5 版纸装载键.被按下 6 纸传感器.光路被挡 7 纸检测传感器.光路被挡 8 A位传感受器.光路被挡 9 0角度传感器.磁力检测 10 180角度传感器.磁力检测 11 C位传感器.光路被挡 12 进纸台下降键.被按下 13 夹板安全开关.开关被按下 14 卸版爪传感器.光路被挡 15 版纸位置传感器.反射光检测 16 滚筒原始位置键.被按下 18 滚筒装置开关.开关被按下 19 接纸传感器.光路被挡 20 接纸传感器2.光路被挡 21 扫描台(上盖)装置开.开关被按下 22 垂直位置传感器.光路被挡 23 版纸用完传感器.无反射光 24 进纸离合器传感器.光路被挡 25 进纸检测传感器.光路被挡 26 跳翼开关1.开关被按下 27 跳翼开关2.开关被按下 28 卸版传感器.光路被挡 29 版纸装载单元开关.开关被按下 30 前门传感器.磁性开关接上 31 热打印头原始位置开.开关被按下 32 热打印头压力开关.开关被按下 33 废版盒装置开头.开关被按下 34 ADF原稿检测传感器.光路打开 35 原稿对位传感器.光路打开 36 进稿传感器.光路被挡 37 油墨传感器.检测油墨 38 油墨溢出传感器.检测油墨 39 主电机安全开关.开关被按下
( 工作计划) 单位：____________________ 姓名：____________________ 日期：____________________ 编号：JH-XK-0823 2021年市场推广工作计划范例 Example of 2020 marketing plan
2021年市场推广工作计划范例(最 新版) 一、进一步积极努力地做好各地校友会工作继续加强与校友的联系沟通，充分整合与利用学院与校友资源，促进学院发展， 市场推广工作计划。协调和策划好各地校友会的工作，校友工作办公室将加大工作力度，充分发挥各相关部门的力量，利用有关领导、教师与广大校友的关系，尽快把各地校友会建立起来。对已经建立了26个校友分会，倡导他们积极开展活动；在一些条件比较成熟但未成立校友分会的地方，如内蒙、广西、青海、山西、盐城、扬州、***等地，将加大工作力度，指导、帮助他们尽快把校友分会成立起来，争取在年底成立5个校友分会。在校友活动尚比较松散的其他地区，着力发展一批热心校友工作的积极分子，协调、促成他们牵头做好校友会组织的筹备工作。 二、进一步建立健全校友会组织建立健全校友会各职能机构，明确分工、定职定责，做好20XX年校友会工作。拟在10月下旬到11月中旬邀请各地分会会长、副会长及秘书长召开徐州建筑职业技术学院校友联谊会第二次理事大会。为此我们设计两个方案实施。方案一：借上海世博会机会，在上海周边召开第二次理事大会。方案二：借成立新的校友分会机会，召开第二次理事大会。希望校
友会理事会年会常态化，每年召开一次，由各地分会联办或独立承办的方式召开。我们要在徐州建筑职业技术学院校友联谊会理事大会会议精神的基础上进一步健全校友会组织。1、做好成立新的校友分会的调研摸底工作，根据需要和相关条件逐步完成；2、建立校友会理事会各成员间的联系制度，交换信息，沟通思想，为建设一个讲大局、讲友谊、讲***、有效率的理事会创造条件。 三、收集校友信息，完善校友通讯录通过查档、访人摸清建校来历届毕业生的去向等情况，建立校友基础档案，在校庆通讯录基础上，进一步完善。为开展校友会工作做好相应的准备。1、寻迹。根据有关线索，先易后难，搜集历届毕业生的去向；2、挂钩。通过各种渠道与校友取得联系；3、造册。通过查访寻迹，将收集到的历届毕业生名单登记造册；4、分类。按校友的职业门类、当前状况、个人特点等分类编排，分组建档立案，并选择其中一些人作为类型代表加强联系，为学校的教育教学提供参考，工作计划《市场推广工作计划》。 四、做好校友会宣传工作校友工作是系统工程、全员工程、爱心工程，全体在校的教职员工及广大校友，都是工作主体，也是工作对象，都要不断加深对校友会工作重大意义的认识，进一步明确校友是母校立身的基本支柱，是母校发展的战略资源；为学子、校友成长服务就是为学校建设发展服务，因此我们一定要同心协力做好校友工作。1、配合学校工作，宣传学院建校30年以来的取得的巨大变化，宣传学校未来的改革和发展，使社会了解学校，使广大校友及时听到母校的声音，促进彼此情感的沟通，激发校友关心母校献身祖国的热情；2、配合学校宣传部门，围绕社会主义荣誉观的宣传教育，宣扬学校的优良作风，树立学校良好形象，强化师生意识、爱生意识和责任意识，以身为范，使爱生、爱校、敬业、诚信、文明、礼貌的根深深地埋在未来校友的心中；3、深入宣传校友会
理想一体机维修代码GR\FR系列 理想GR一体机测试代码 第一部份：自检功能（用来检测每个电器部件是否正常） 开始测试操作]（同时按下“线条稿/照片”和“制版/印刷”按键，打开电源。） 用两种不同的叫声区别当前测试元器件状态是否正常（检测到： 0.1秒间隔的叫声）1）[传感器/开关测试]. 2 纸尺寸传感器. 反射光检测 3 限传感器. 光路被挡 4 进纸压力开关.开关打开 5 版纸装载键.被按下 6 纸传感器.光路被挡 7 纸检测传感器.光路被挡 8 A位传感受器.光路被挡 9 0角度传感器.磁力检测 10 180角度传感器.磁力检测 11 C位传感器.光路被挡 12 进纸台下降键.被按下 13 夹板安全开关.开关被按下 14 卸版爪传感器.光路被挡 15 版纸位置传感器.反射光检测 16 滚筒原始位置键.被按下 18 滚筒装置开关.开关被按下 19 接纸传感器.光路被挡 20 接纸传感器2.光路被挡 21 扫描台(上盖)装置开.开关被按下 22 垂直位置传感器.光路被挡 23 版纸用完传感器.无反射光 24 进纸离合器传感器.光路被挡 25 进纸检测传感器.光路被挡 26 跳翼开关1.开关被按下 27 跳翼开关2.开关被按下 28 卸版传感器.光路被挡 29 版纸装载单元开关.开关被按下 30 前门传感器.磁性开关接上 31 热打印头原始位置开.开关被按下 32 热打印头压力开关.开关被按下 33 废版盒装置开头.开关被按下 34 ADF原稿检测传感器.光路打开 35 原稿对位传感器.光路打开 36 进稿传感器.光路被挡
37 油墨传感器.检测油墨 38 油墨溢出传感器.检测油墨 39 主电机安全开关.开关被按下 40 进纸安全开关.开关放开 41 进纸盒开关1.磁性检测 42 进纸盒开关2.磁性检测 43 进纸盒开关3.磁性检测 44 进纸盒开关4.磁性检测 45 出稿传感器.光路被挡 46 ADF开关.开关被按下 47 版纸检测开关.反射光检测 48 版纸用完传感器.反射光检测 49 扫描器原始位置传感.光路被挡 50 ADF扫描自动匀色传.光路被挡 51 稿台盖传感器.光路被挡 52 稿台原稿检测传感器.反射光检测 53 压力控制传感器.光路被挡 54 废版检测传感器.光路被挡 55 油墨筒开关1.开关被按下 56 油墨筒开关2.开关被按下 57 油墨筒开关3.开关被按下 58 电池检测信号.电池 59 接口板检测信号.选配件接口板接上 2）[电机/电磁铁测试] 60 滚筒15转/分钟 61 滚筒30转/分钟 62 滚筒变速运转 63 分离风扇 65 写入步进电机CW(输入) 66 装载步进电机 67 进纸电磁离合器 68 压力电磁铁 69 负压风扇 70 卸版风扇 71 卸版电磁铁和卸版输送电机 72 装载风扇 73 夹板电磁铁 74 锁定电磁铁(滚筒) 75 拾稿电磁铁 77 热打印电力控制 78 进稿电机 79 图像扫描LED列阵点亮 80 翼电机(GR1700除外) 90 部分内存清除.系统电路板上RAM的部分信息,如卡纸和故障信息被初始化. 91 制版宽度检查. 92 使印刷、制版和磁卡计数器不工作.同时"T17 CALL SERVECE"或E17也不显示.允许维修技术
市场推广部年度工作计划3篇 所谓市场推广是指企业为扩大产品市场份额，提高产品销量和知名度，而将有关产品或服务的信息传递给目标消费者，激发和强化其购买动机，并促使这种购买动机转化为实际购买行为而采取的一系列措施。为了更好开展市场推广的工作，制定年度的工作计划。本文是市场推广部的年度工作计划，欢迎阅读。 市场推广部年度工作计划一： 受两方的促销。 ·如建材超市渠道：与渠道共同承担、联合组织店长推荐、单品超低特价等终端促销活动 注：此项活动可由区域经销商自行组织终端促销活动，公司可根据情况提供物料支持和费用支持; 2.2.3、现场推广活动 选择5-6个重点区域，结合商业照明产品的上市，根据上市产品特性设计一系列的产品特点演示、产品体验环节，配合生动化的终端展示物料，现场设计一新闻点，进行新闻软文、报道炒作。 发布方式：由公司提供活动物料及策划、媒体报道支持，活动区域经销商承担场地、工商、城管费用以及活动信息发布、人员费用。 2.2.4、 "让更多人拥有理想(安尚品牌主张)的照明空间"照明应用设计普及风暴 以公司照明设计组为主要力量，在全国各地联合特约家装、工装公司设计力量，在家装与商业店铺装修高峰期推出免费为客户提供专业照明设计的活动，客户通过经销商将房屋的室内规划图、结构图等相关图纸以及需求介绍发至公司照明设计组或特约家装、工装公司，即可享受免费的照明设计服务，并可享受购买安尚产品的优惠。
结合2005年中国节约年的影响以及世界能源紧张的现状，借力中央电台每天呼吁的"节约中国"的广告语，在2005年年底的新产品推出的时候以高端软文、新闻报道、平面广告的等高端媒体的舆论炒作，建立品牌形象，配合对节能产品的终端赠品促销、终端物料宣传，形成一个立体化的推广活动。 2.2.6、"五子登科"大派财——福、禄、寿、喜、财 主要针对流通类产品在元旦以后至农历正月15日期间以刮刮卡的形式为客户派送红包：分别分为福如东海奖、禄厚官高奖、寿比南山奖、喜气洋洋奖、财源滚滚奖分别设置不同金额的红包。 活动开展方式：公司提供策划、广告宣传、广宣物料费用，经销商承担奖品费用; 2.2.7、日常广宣物料、促销礼品等提供，作为区域性、短期促销物料。 3、公关活动 3.1、主要合作媒体：(待定) 3.2、媒体关系管理 与行业内专业媒体以及相关大众媒体建立良好的合作关系，通过新闻采访，增加企业与客户、见面的机会，将市场上的每一次动作、每一次新产品的推出都能站在更高的高度展现在大众面前;如：根据产品上市情况以新闻发布的形式邀请部分在行业内有影响力的专业报刊、杂志、网站对新产品进行感受、了解，并以新闻通稿的形式营造短期内的产品上市新闻热点。 3.3、区域房产活动赞助 赞助类似商业步行街开发商主办的如：招商会、封顶典礼之类的活动，提升区域内客户对品牌的关注度;
计算机、打印机维护方案
1.计算机硬件维护手册 容易引起电脑不稳定的几个因素 一、灰尘 部分个人客户在组装完电脑后，使用中可能喜欢把机箱盖打开，为了方便更换和调试硬件及有利子加强散热：部分网吧客户工作强度大和使用环境比较“严峻”，这样长时间使用会容易导致硬件表面聚集灰尘，其可能带来的影响如下： 1．可能会引起短路： 2．插槽及接口接触不良： 3．粘附风扇引起散热良。 二、温度 电脑在使用一段时间后，灰尘等污物会在机箱内、外部的积淀或者因不确定因素的导致cpu、主板、显卡、硬盘等配件局部温度或机箱内部环境温度过高，从而导致的硬件的散热不良，进而引发电脑的不稳定或者出现硬件等故障。 三、其他 静电、电源未正常接地等导致的电脑的不稳定及硬件不工作和损坏等故障。 电脑维护指南 维护补助物品 十字螺丝刀、一字螺丝刀、毛刷(或者油画笔，不建议使用易脱毛的)、干抹布、导热硅胶等，有条件可以选用防静电设计的吹风机或者吸尘器。 一、注意事项 1 拆机前切断电源： 2 拆装前尽量不要穿毛皮衣服，把工具和手放到电物体上(例如自来水管等)接触释放静电，强烈建议使用青电手套操作：
3 物品务必轻拿轻放： 4 拆装的时候注意螺丝的正确安装、数据线及电源线的合理插拔，不可用蛮力、暴力： 二、开始操作 1．外部硬件清理 显示器 显示器使用注意事项，个人客户不要为了防尘斥把显示器穿上外套，这样是非常不利于散热的，可在在显示器上方距离一尺左右的地方放置一个遮盖物品，减少灰尘的危害，建议客户采用一周不少于一次的显示器定期清洁； 键盘鼠标 键盘鼠标的清理建议客户每天不低于一次的清理： 如果不慎键盘进入液体，应当立刻关闭计算机后更换键盘后再使用，以免带来不必要的意外损失。 2．主机内部清理 主机电源 有条件选用防静电设计的吹风机或者吸尘器清理的客户，电源的风扇口吹风或者吸尘是最理想的清洁方案，采用毛刷将粘附在主机电源风扇及内部通风口位置上面的灰尘刷掉，然后通电几秒种，让电源风扇把刷下的灰尘吹出即可； cpu风扇 cpu风扇的清理最好是可以把cpu风扇拆卸下来，把cpu风扇的灰尘刷干净后，请注意cpu风扇底部和表面接触的导热硅胶是否已经风干和结块，如果出现此情况注意务必先把cpu风扇底部和cpu表面的导热胶清理干净，再将准备好的硅胶涂抹适量到已经正确安装到主板上的cpu表面，以避免新旧导热胶的混用导致散热不良。 主板 主板是承载计算机其他硬件的平台，其表面积大，灰尘相对比较多，注意清理主板的时候，尽量不要把主板拆离机箱，采用毛刷他细刷干净表面灰尘，注意不要硬物伤害电子元件和划伤电路板：